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
