On Wed, Aug 24, 2016 at 11:32 AM, Sanjeewa Malalgoda <[email protected]> wrote:
> 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? > Yes. Thank you. > >> >> 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/> > > > -- 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
