Hi All, Following document contains the main scenarios we plan to cover from the initial implementation and how we implement them. Since we plan to use a scope based method to separate the API product related calls from normal APIs, we need to identify the places where this could affect APIs which are not related to API products. ( ex: how APIs having resources without scope would work if we assign system defined scopes for resources.). Please raise any concerns you would see which may affect the normal API invocations, etc so that we could come up with a better design.
[1] https://docs.google.com/document/d/1TNLojtKPbTcR2bZcjCAwIwAPK2UrJptKeAHlgOmePeM/edit?usp=sharing Any thoughts and suggestions in this regard are highly appreciated. Thanks Chamila. 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. > > [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. > > * 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 > > -- Regards, Chamila Adhikarinayake Associate Technical Lead WSO2, Inc. Mobile - +94712346437 Email - [email protected] Blog - http://helpfromadhi.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
