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 <chath...@wso2.com>
wrote:

>
>
> On Wed, Apr 10, 2019 at 9:22 AM Sachini De Silva <sachi...@wso2.com>
> 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 <chath...@wso2.com>
>> 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 <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
>>>>
>>>>
>>
>> --
>>
>> *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
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to