Re: [Architecture] [APIM] Introduce API Product Concept
Hi,
Currently, the request to add a subscription looks like below. Based on API
subscription or product subscription, we need to define *apiIdentifier* or
*apiProductIdentifier*
POST /subscriptions
{
"applicationId":"<>",
"apiIdentifier":"<>",
"apiProductIdentifier":"<>",
"tier":"<>"
}
I am not seeing a real benifit of using the same resource as the caller
needs to be anyway aware whether he is doing a API subscription or a
product subscription (he needs to fill either apiIdentifier or
*apiProductIdentifier* depending on the case.
How about adding two different resources as below. As we are anyway
rewriting the REST APIs for APIM 3.0, we can do changes to the existing
APIs.
POST /subscriptions/api (ie. existing POST /subscriptions -> renamed to
POST /subscriptions/api)
{
"applicationId":"<>",
"apiId":"<>",
"tier":"<>"
}
POST /subscriptions/api-product (new resource for product subscriptions)
{
"applicationId":"<>",
"apiProductId":"<>",
"tier":"<>"
}
Thanks!
On Thu, Apr 18, 2019 at 9:48 AM Chamila Adhikarinayake
wrote:
> Hi Chathura,
>
> The plan is to have only subscription level throttling policy for API
> Product (This is similar to API's subscription policy). All the policies
> related to APIs (resource level, api level) are kept as it is. So if the
> resource has a 10TPS , it will still have that policy if that resource is
> included in a product. When validating the subscription level throttling,
> For product we check the product's subscription level throttling value
> instead of the subscription policy of the API which has the resource.
>
> On Wed, Apr 17, 2019 at 1:39 PM Chathura Ekanayake
> wrote:
>
>>
>>
>> On Wed, Apr 10, 2019 at 9:22 AM Sachini De Silva
>> wrote:
>>
>>> 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.
>>>
>>
>> If a resource R1 has a throttling limit of 10 TPS and an API product
>> containing that resource has a throttling limit of 100 TPS, how many
>> requests can be sent to R1 per second? Is it 10 TPS?
>>
>>
>>> "*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
>>> 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
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
Re: [Architecture] [APIM] Introduce API Product Concept
Hi Chathura, The plan is to have only subscription level throttling policy for API Product (This is similar to API's subscription policy). All the policies related to APIs (resource level, api level) are kept as it is. So if the resource has a 10TPS , it will still have that policy if that resource is included in a product. When validating the subscription level throttling, For product we check the product's subscription level throttling value instead of the subscription policy of the API which has the resource. On Wed, Apr 17, 2019 at 1:39 PM Chathura Ekanayake wrote: > > > On Wed, Apr 10, 2019 at 9:22 AM Sachini De Silva > wrote: > >> 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. >> > > If a resource R1 has a throttling limit of 10 TPS and an API product > containing that resource has a throttling limit of 100 TPS, how many > requests can be sent to R1 per second? Is it 10 TPS? > > >> "*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 >> 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 >>> 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 >> >> -- >> >> *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 > -- Regards, Chamila Adhikarinayake Associate Technical Lead WSO2, Inc. Mobile - +94712346437 Email - chami...@wso2.com Blog - http://helpfromadhi.blogspot.com/ ___ Architecture mailing list
Re: [Architecture] [APIM] Introduce API Product Concept
On Wed, Apr 10, 2019 at 9:22 AM Sachini De Silva wrote: > 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. > If a resource R1 has a throttling limit of 10 TPS and an API product containing that resource has a throttling limit of 100 TPS, how many requests can be sent to R1 per second? Is it 10 TPS? > "*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 > 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 >> 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 >>> >>> > > -- > > *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
Re: [Architecture] [APIM] Introduce API Product Concept
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 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 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 >>> 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 >> >
Re: [Architecture] [APIM] Introduce API Product Concept
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 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 >> 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
Re: [Architecture] [APIM] Introduce API Product Concept
+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 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
Re: [Architecture] [APIM] Introduce API Product Concept
Hi All, Please find the rests APIs for Publisher[1] and store[2] for API Product. New rest APIs are introduced except for store's /subscriptions/* resources (New element for apiproductId is added to the existing payload ) [1] https://app.swaggerhub.com/apis-docs/chamilaadhi/wso-2_api_manager_publisher_api/0.14.0 [2] https://app.swaggerhub.com/apis-docs/chamilaadhi/wso-2_api_manager_store/0.14.0#/ Thanks, Chamila. On Wed, Apr 10, 2019 at 9:35 AM Nuwan Dias wrote: > In addition to bundling APIs, an important feature with API products is > the ability to create products with only parts of APIs. For example you > have an API with 20 resources that performs various actions. You may want > to create 2 API products with that API. One product with only the read-only > operations of that API (5 resources) and sell it at a certain price. And > the other product with all operations available at a higher price than the > former. > > On Wed, Apr 10, 2019 at 9:22 AM Sachini De Silva > wrote: > >> 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 >> 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 >>> 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 >> >> -- >> >> *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 >> > > > -- > *Nuwan Dias* | Director | WSO2 Inc. > (m) +94 777 775 729 | (e)
Re: [Architecture] [APIM] Introduce API Product Concept
In addition to bundling APIs, an important feature with API products is the ability to create products with only parts of APIs. For example you have an API with 20 resources that performs various actions. You may want to create 2 API products with that API. One product with only the read-only operations of that API (5 resources) and sell it at a certain price. And the other product with all operations available at a higher price than the former. On Wed, Apr 10, 2019 at 9:22 AM Sachini De Silva wrote: > 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 > 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 >> 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 >>> >>> > > -- > > *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 > -- *Nuwan Dias* | Director | WSO2 Inc. (m) +94 777 775 729 | (e) nuw...@wso2.com [image: Signature.jpg] ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Introduce API Product Concept
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 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 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 >> >> -- *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
Re: [Architecture] [APIM] Introduce API Product Concept
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 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 : sachi...@wso2.com > Mobile : +94714765495 > > -- Regards, Chamila Adhikarinayake Associate Technical Lead WSO2, Inc. Mobile - +94712346437 Email - chami...@wso2.com Blog - http://helpfromadhi.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Introduce API Product Concept
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 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] [APIM] Introduce API Product Concept
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 : sachi...@wso2.com Mobile : +94714765495 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
