Alternatively we could use the term 'API Package' (analogous to a mobile service provider package) to define a group of APIs with their own set of policies.
On 30 August 2016 at 13:12, Imesh Gunaratne <[email protected]> wrote: > Thanks, Uvindra! I can only see this concept being used at [1]. Do you > have any other references? > Still, I don't think the product term is well suited for grouping APIs. > > [1] http://docs.apigee.com/developer-services/content/what-api-product > > > On Tue, Aug 30, 2016 at 11:52 AM, Uvindra Dias Jayasinha <[email protected] > > wrote: > >> 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 <[email protected]> wrote: >> >>> Hi Sanjeewa, >>> >>> On Tue, Aug 23, 2016 at 3:07 PM, Sanjeewa Malalgoda <[email protected]> >>> 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 777733962 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> 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 > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
