+1 to allowing subscriptions to API products only, I dont see an advantage in supporting both subscriptions to APIs and API products(it only complicates things). This will also eliminate confusion for subscribers. Yes there will be a migration effort in doing this but its worth it IMO for the clean integration of this feature into the product.
On 24 August 2016 at 15:01, Sanjeewa Malalgoda <[email protected]> wrote: > > > On Tue, Aug 23, 2016 at 6:00 PM, Nuwan Dias <[email protected]> wrote: > >> >> >> On Tue, Aug 23, 2016 at 3:07 PM, Sanjeewa Malalgoda <[email protected]> >> wrote: >> >>> Hi All >>> >>> Intention of this mail is to discuss about API product concept and try >>> to evaluate how we can apply this for API Manager. As of now we can bundle >>> APIs together into application at API store and use them. But in this >>> feature we are mainly focus on API publisher side aspect of it(how >>> publishers can bundle set of APIs and present it to application creator). >>> Please find the details below and share your thoughts about them. >>> >>> >>> *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). >>> >> >> Combining APIs is one requirement. Another use case is that a API >> publisher (product manager) uses a single API definition to create multiple >> API products. Ex: You get API 'foo', attach tiers x, y and z and call that >> API Product Alpha, you get the same API 'foo', attach tiers p, q and r and >> call that API Product Omega. Now >> >>> >>> *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. >>> >> >> Generating the "throttle key" is the key here. Instead of making the >> throttle key unique to the API (having the API context and version), for >> API product accesses if we create the throttle key that's unique to all >> APIs within that product, that should do the trick. >> > Yes this should be possible. > >> >>> *Key Manager side.* >>> While validating subscription we can check API level subscription and >>> API product level subscription both. >>> >> >> I don't think we need to do any changes to key validation. When someone >> subscribes an Application to an API product, if we create subscriptions to >> that Application for each individual API, we should be able to live with >> the subscription validation we have in place today. >> > If we make it subscribe to each individual API then it will be same as > application subscribe to multiple API. What i think is users should > subscribe to API. Then when we validate subscription first we need to get > API product and do validation to API level. Also accessing API product > level subscription and getting details will be helpful for subsequent calls > if we check implementation carefully. To check application level and > subscription level throttling we use information we retrieve while > validating subscription. So we may need to do same for API product as well. > > Thanks, > sanjeewa. > >> >>> 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 >>> >>> >> >> >> -- >> Nuwan Dias >> >> Software Architect - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > *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 > > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
