Hi Imesh, Yes the term API Product has already been coined by the industry. It makes sense to use this term because we allow different API products to have different policies associated with them. So its not just a grouping of APIs, you can have the same set of APIs grouped together with different policies associated with them as different API product instances.
On 30 August 2016 at 07:19, Imesh Gunaratne <im...@wso2.com> wrote: > Hi Sanjeewa, > > On Tue, Aug 23, 2016 at 3:07 PM, Sanjeewa Malalgoda <sanje...@wso2.com> > wrote: > >> >> *Requirement* >> >> As an API provider(creator or publisher), you need to create an API >> product. The API product is the mechanism through which your APIs are >> bundled and published so that developers can consume them. An API product >> is a collection of APIs combined with a predefined policy set presented to >> developers as a bundle(in a way they can subscribe to product and use it). >> > > What would be the reason for choosing > > the term "product" for grouping a set of APIs? Is that something already > used in the industry in the API-M context? > > If not, I think it would it be more > > meaningful > to call it > an API group because the term "product" may conflict with Carbon > products and would be difficult to understand at first sight. > > Thanks > >> >> *Proposed Solution* >> >> The API product can also include some information specific to your >> business/product for monitoring or analytics. You can create different >> products to provide features for different use cases. So instead of just >> giving developers a list of APIs, you can bundle specific resources >> together to create a product that solves a specific user need. As example >> we can consider following use case. >> >> Example: >> Let say we have user information API, credit service API, leasing API. >> And let say we need to have 2 mobile applications for credit and leasing. >> Then we can create 2 API products named credit API product and leasing API >> product(both will share user information API). API products are also a good >> way to control access to a specific bundle of APIs. For example, you can >> bundle APIs that can only be accessed by internal developers, or bundle >> APIs that can only be accessed by paying customers. Please see following >> diagram to understand this scenario. >> >> >> >> >> >> >> >> >> *Implementation Details.**From Publisher's side.* >> From publisher side we need to let users to create API products like we >> do for APIs. To do that we may need to provide user interface similar to >> API create. In this API product creation process we collect following >> information from product creator. >> >> - Product Name and product specific meta-data. >> - List of APIs belong to that product and their tiers used for >> product. >> - Visibility and subscription availability. >> - Tiers and access control related information. >> - Life-cycle management for API product. >> >> *From store side.* >> List products same way we list APIs and then let users to subscribe for >> API Products. Once we go to subscription users should be able to see apis >> and api products belong to application. Also when we go to specific API >> product then we should be able to see all APIs belong to that API and >> selectively go through them. We will not be able to have single swagger >> file or wadl for complete API product as it shares multiple APIs. >> >> *Gateway Side.* >> For the throttling we need to do some improvements to throttle API >> product level requests. While doing throttling we need to consider number >> of requests allocated for API product as well and then consider that for >> throttling. >> >> *Key Manager side.* >> While validating subscription we can check API level subscription and API >> product level subscription both. >> >> Please share your thoughts on this. >> >> Thanks, >> sanjeewa. >> >> -- >> >> *Sanjeewa Malalgoda* >> WSO2 Inc. >> Mobile : +94713068779 >> >> <http://sanjeewamalalgoda.blogspot.com/>blog >> :http://sanjeewamalalgoda.blogspot.com/ >> <http://sanjeewamalalgoda.blogspot.com/> >> >> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Imesh Gunaratne* > Software Architect > WSO2 Inc: http://wso2.com > T: +94 11 214 5345 M: +94 77 374 2057 > W: https://medium.com/@imesh TW: @imesh > lean. enterprise. middleware > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
