Hi Chathura, Please find my answers below.
"*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?*" Resource level policies will be inherited from underlying APIs. API level subscription policy will get overridden by product level subscription policies. "*So when getting a token does the user has to specify the API product scope and the resource scope (if any)?*" Yes, normal oauth scope rules will not get affected. Thanks, Sachini On Tue, Apr 9, 2019 at 2:20 PM Chathura Ekanayake <[email protected]> wrote: > 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 <[email protected]> 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 : [email protected] >> Mobile : +94714765495 >> >> -- *Sachini De Silva* Software Engineer - WSO2 Email : [email protected] Mobile : +94714765495
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
