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 <[email protected]>
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 <[email protected]>
> wrote:
>
>>
>>
>> On Wed, Apr 10, 2019 at 9:22 AM Sachini De Silva <[email protected]>
>> 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 <[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
>>
>
>
> --
> 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
>
--
Malintha Amarasinghe
*WSO2, Inc. - lean | enterprise | middleware*
http://wso2.com/
Mobile : +94 712383306
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
