Hi All, Thank you for your suggestions. Please find comments in-line. On Wed, Aug 24, 2016 at 10:33 AM, Thilini Cooray <[email protected]> wrote:
> Hi Sanjeewa, > > I would like to have couple of clarifications > > > - When invoking an API product by the user, how will be the mediation > flow happen among the APIs? > - Are we going to allow the API product creator to define it? > > This will be same as invoke APIs. API product is just a logical grouping and it will not change runtime or mediation flow. This is slightly different from API composition where we let users to compose API and let them do define mediation flow. > > On Wed, Aug 24, 2016 at 9:39 AM, Sumedha Rubasinghe <[email protected]> > wrote: > >> Harsha, >> If we take a vanilla API manager distribution and deploy an API there can >> we call it an API product? >> >> On Aug 24, 2016 9:27 AM, "Harsha Kumara" <[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). >>>> >>>> *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 >>>> >>> > > When creating the API product, are we going to provide the capability of > selecting only a set of resources from each API and bundle together instead > of adding all the resources of each API? > Yes this is very valid argument and some of other API platforms allow this. But i see this in different way. API is a logical group of resource which grouped by its functionality or service it exposed. So IMHO we shouldn't break it further to resource level when we create API products. If we have too many resources within API that cannot logically fall under same category then we should create few APIs from that. And even with current implementation we will not let users to subscribe for resources. Is this make sense? > > > That means, are we going to have resource level subscriptions > (limiting access to only those resources) or API level with all resources > (eventhough those resources are not supposed to be accessed via the > product)? > > > Thanks. > > >> 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. >>>> >>> I think we need to introduce new throttling scheme for API products when >>> someone going to subscribe to a API product. In default scenario, we show >>> what are the available subscription tiers for API when user going to >>> subscribe to a API. But for a API product, it will contains multiple APIs. >>> Hence we need to have a way to define allowed throttling tiers for API >>> product. Which will be show when user going to subscribe to API product. >>> But I think, we also need to think, what are the available subscription >>> level throttling tiers defined by underline APIs. >>> >> Yes this is true. We can let users to subscribe API products and APIs both. When they subscribe to product they will see certain tiers and need to select one of them. When they use product by going to product description they should see API allocated requests within the product. Its more like APIs subscribe to product. Or we can do some other major changes to make things easy. One option is let users to subscribe only API products. Then no API concept will be there in store anymore. Each and everyone need to subscribe to API products only. Still we need to discuss this further and come to conclusion. > >>> *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 >>>> >>>> >>> >>> >>> -- >>> Harsha Kumara >>> Software Engineer, WSO2 Inc. >>> Mobile: +94775505618 >>> Blog:harshcreationz.blogspot.com >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Best Regards, > > *Thilini Cooray* > Software Engineer > Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194> > E-mail : [email protected] > > WSO2 Inc. www.wso2.com > lean.enterprise.middleware > -- *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
