Hi, For now, we have no intention to force migrate existing APIs to API products so that there will be only API products in API store. Publishers can expose their APIs to store directly as they did earlier. Additionally, with API product feature they can bundle APIs/subsets of resources from several APIs as a single API product. The store will have a separate view for API Products. So basically, API Manager will have both APIs and API Products in store.
Thanks, Sachini On Thu, Apr 11, 2019 at 4:30 PM Cyril Rognon <crog...@gmail.com> wrote: > Hi all, > > +1 for your feedback Franck : APIProduct should not be only a group of API > but the public face of the API. Meaning an API has to be a product if > consumed. > > We could think of an automated way to promote an existing API as a > Product. Hence the store would only show API Products whereas the publisher > would allow to work with APIs and their Product counterpart (either a > partial view or a group or ...). > > Thanks > Cyril > > Le jeu. 11 avr. 2019 à 11:33, Frank Leymann <fr...@wso2.com> a écrit : > >> +1 , this is a useful feature (although we may invent another name for >> a group of APIs, because a single API today is subject to monetization, >> i.e. a "product"). >> >> Generalizing Chathura's question: do non-functional properties defined >> at the collection level (throttlling, security, pricing,...) override the >> corresponding properties at the "member-API" level? Can such properties >> defined both, at the level of the whole collection as well as at the level >> of individual members? >> >> Best regards, >> Frank >> >> >> >> >> Am Di., 9. Apr. 2019 um 10:50 Uhr schrieb Chathura Ekanayake < >> chath...@wso2.com>: >> >>> Hi Sachini, >>> >>> Grouping APIs as mentioned is an useful feature. Few comments inline.. >>> >>> On Tue, Apr 2, 2019 at 2:25 PM Sachini De Silva <sachi...@wso2.com> >>> wrote: >>> >>>> Hi all, >>>> >>>> We are planning to introduce API product concept to API Manager. >>>> >>>> An API product is basically a bundle of APIs/ API resources that is >>>> made available to users to subscribe and consume. API product creator can >>>> attach a throttling policy and other metadata to the API product. The >>>> collection of APIs/resources in the product are such that they address a >>>> specific business use case. >>>> >>>> For example, I have 3 APIs as below. And I need to bundle API A and B >>>> together, attach a higher throttling limit and make it available for paid >>>> customers. And bundle API B, C together with a lower throttling limit and >>>> make it available for free use. >>>> >>> >>> How does API product level throttling work with API/resource level >>> throttling? Does it override API/resource level throttling? Or does the >>> most restrictive policy apply? >>> >>> >>>> >>>> [image: image.png] >>>> >>>> Below is how we are planning to implement this feature on APIM. >>>> >>>> 1. When a user creates an API product a new scope(without any role >>>> assigned) will be created and attached to all the api resources he/she is >>>> allowing for that API product. >>>> 2. Then a user can subscribe to the api product and in order to get a >>>> token for the API product, he/she has to pass the scope details along with >>>> the token request. >>>> 3. So that the request can be identified as coming through the API >>>> product and handled accordingly. >>>> >>>> The reason for using this scope based approach is to avoid creating a >>>> new gateway resource for the APIs in the product. In above, the requests >>>> will be directed to the existing APIs deployed in the gateway and the >>>> request will be distinguished as coming from an API product by using the >>>> scope attached to the access token. >>>> >>>> Following are several concerns we identified and appreciate your >>>> thoughts and suggestions on them. >>>> >>>> * At the moment an API resource can’t be assigned multiple scopes. - we >>>> are currently looking into this. >>>> >>> >>> So when getting a token does the user has to specify the API product >>> scope and the resource scope (if any)? >>> >>> >>>> * We are planning to introduce a new API product throttling level. At >>>> the moment we are further looking into throttling and analytics for API >>>> products. >>>> >>>> * With regard to UI aspects, we will be adding a new section in API >>>> publisher UI to create and modify API products. And in store, we will be >>>> adding a new section to view and subscribe to API products. >>>> >>>> Thanks, >>>> Sachini >>>> -- >>>> >>>> *Sachini De Silva* >>>> Software Engineer - WSO2 >>>> >>>> Email : sachi...@wso2.com >>>> Mobile : +94714765495 >>>> >>>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Sachini De Silva* Software Engineer - WSO2 Email : sachi...@wso2.com Mobile : +94714765495
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
