Hi Malintha
The POST should go to /tiers/{tier-level} since if you are posting /tiers
you need to add an additional parameter. BTW is the tier model same for all
the levels ?
Thanks
Jo
On Tue, Dec 1, 2015 at 5:40 PM, Malintha Amarasinghe <[email protected]>
wrote:
> Hi Nuwan,
>
> Thanks for the clarification.
>
> Hi Frank,
>
> Yes, would that need to be changed for POST /tiers/{tier-level}? Or shall
> we keep the previous one (/tiers ) only for POST and identify the tier
> level from the request body?
>
> Thanks.
>
>
> On Tue, Dec 1, 2015 at 5:32 PM, Frank Leymann <[email protected]> wrote:
>
>> Just to double-check: but we still have a POST /tiers to add a new tier
>> to the collection, right?
>>
>>
>> Best regards,
>> Frank
>>
>> 2015-12-01 11:50 GMT+01:00 Nuwan Dias <[email protected]>:
>>
>>> I think the group param should be mandatory. Therefore there will not be
>>> a GET /tiers, but instead a GET /tiers/{level} only.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Tue, Dec 1, 2015 at 3:17 PM, Malintha Amarasinghe <[email protected]
>>> > wrote:
>>>
>>>> Hi Nuwan, Sanjeewa and Joe,
>>>>
>>>> Thanks a lot for all the suggestions.
>>>>
>>>> I have a small doubt for using the group as part of the path.
>>>>
>>>> Lets say we use GET /tiers/api/{tier-id} to get a single API tier by
>>>> its id (actually Name). Then, are we exposing the resource /tiers alone
>>>> too? If we do, are we returning the tier groups for GET /tiers? In this
>>>> case, returning tiers will not be appropriate IMO as the immediate
>>>> sub-resource is not a tier, but a tier type. Or can we just make the group
>>>> parameter mandatory?
>>>>
>>>> Thank you.
>>>> Malintha
>>>>
>>>> On Tue, Dec 1, 2015 at 11:54 AM, Nuwan Dias <[email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Dec 1, 2015 at 11:21 AM, Joseph Fonseka <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> IMO if we have multiple tier files a path param would be more
>>>>>> suitable. If we have only one tier file and the group(level) is an
>>>>>> attribute then we could have use a query param.
>>>>>>
>>>>>> Any specific reason to have a tier file for each level ? Rather than
>>>>>> having an attribute to group tiers. Or for each tier specifying
>>>>>> application,
>>>>>> API and resource level throttling separately.
>>>>>>
>>>>>
>>>>> Having everything on a single file makes the tier definitions very
>>>>> noisy. Having it separately makes it very clean and easy to manage.
>>>>>
>>>>> For example, the API tiers now have attributes related to billing
>>>>> information. These won't make sense for Application level and Resource
>>>>> level tiers. So having them in separate files makes sense IMO. In addition
>>>>> to that having them separately allows us to perform access control for
>>>>> those resources as well.
>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Jo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Dec 1, 2015 at 10:06 AM, Sanjeewa Malalgoda <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> What we agreed last week is let users to fetch tiers based on type,
>>>>>>> It can be either path param like mentioned above or query param
>>>>>>> tiers?tier-level=application.
>>>>>>>
>>>>>>> Existing users will get same set of tiers for application, API and
>>>>>>> resource.
>>>>>>> But new deployments and people who willing to have different levels
>>>>>>> can change them as per requirements.
>>>>>>> Having same names in application, API and resource level with
>>>>>>> different unit time and count may be bit confusing IMO.
>>>>>>> Still nothing will break as we return requested tier list.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> sanjeewa.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Dec 1, 2015 at 8:41 AM, Nuwan Dias <[email protected]> wrote:
>>>>>>>
>>>>>>>> @Sanjeewa, users migrating from older versions of API Manager will
>>>>>>>> have their tiers duplicated across all levels. And its not wrong for
>>>>>>>> users
>>>>>>>> to have the same tier across all levels as well. Therefore having
>>>>>>>> duplicate
>>>>>>>> tier names in different levels is valid scenario.
>>>>>>>>
>>>>>>>> @Jo, yes there's a tier.xml file per group.
>>>>>>>>
>>>>>>>> @Malintha, I think the resource url should be
>>>>>>>> /tiers/{level}/{tier-id}. Ex: GET /tiers/application/Gold.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> NuwanD.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Dec 1, 2015 at 7:51 AM, Joseph Fonseka <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Malintha
>>>>>>>>>
>>>>>>>>> Do we have multiple tier.xml files per group ?
>>>>>>>>>
>>>>>>>>> On Tue, Dec 1, 2015 at 7:41 AM, Sanjeewa Malalgoda <
>>>>>>>>> [email protected]> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Nov 30, 2015 at 11:05 PM, Malintha Amarasinghe <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> With the new REST API for API Manager we are exposing a resource
>>>>>>>>>>> /tiers for retrieving/adding/updating tiers. Additionally we have a
>>>>>>>>>>> sub
>>>>>>>>>>> resource /tiers/{tier-id}.
>>>>>>>>>>>
>>>>>>>>>>> As of now, we have been using tier name as the tier-id. It did
>>>>>>>>>>> not give problems as it could be used to identify a tier uniquely
>>>>>>>>>>> as we
>>>>>>>>>>> were maintaining a single set of tiers for all types (API,
>>>>>>>>>>> application and
>>>>>>>>>>> resources)
>>>>>>>>>>>
>>>>>>>>>>> With the new tier grouping feature, we have defined tiers per
>>>>>>>>>>> app/API and resource separately. We are currently using separate
>>>>>>>>>>> names, but
>>>>>>>>>>> still the admin can modify the tiers.xml files and define tiers
>>>>>>>>>>> with same
>>>>>>>>>>> name for those types, hence identifying tier from tier name can be
>>>>>>>>>>> ambiguous.
>>>>>>>>>>>
>>>>>>>>>> Ideally we will not use same set of names across application, api
>>>>>>>>>> and resources. We agreed to use different set of names for each tier
>>>>>>>>>> types,
>>>>>>>>>> So i think this will not cause any problem.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> sanjeewa.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Because of this problem, would we be able to continue using tier
>>>>>>>>>>> name as the tier id? Can you please give a better suggestion.
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Malintha
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Malintha Amarasinghe
>>>>>>>>>>> Software Engineer
>>>>>>>>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>>>>>>>>> http://wso2.com/
>>>>>>>>>>>
>>>>>>>>>>> Mobile : +94 712383306
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> *Sanjeewa Malalgoda*
>>>>>>>>>> WSO2 Inc.
>>>>>>>>>> Mobile : +94713068779
>>>>>>>>>>
>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>>>>>>>>> :http://sanjeewamalalgoda.blogspot.com/
>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Joseph Fonseka*
>>>>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>
>>>>>>>>> mobile: +94 772 512 430
>>>>>>>>> skype: jpfonseka
>>>>>>>>>
>>>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Nuwan Dias
>>>>>>>>
>>>>>>>> Technical Lead - WSO2, Inc. http://wso2.com
>>>>>>>> email : [email protected]
>>>>>>>> Phone : +94 777 775 729
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> *Sanjeewa Malalgoda*
>>>>>>> WSO2 Inc.
>>>>>>> Mobile : +94713068779
>>>>>>>
>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>>>>>> :http://sanjeewamalalgoda.blogspot.com/
>>>>>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> --
>>>>>> *Joseph Fonseka*
>>>>>> WSO2 Inc.; http://wso2.com
>>>>>> lean.enterprise.middleware
>>>>>>
>>>>>> mobile: +94 772 512 430
>>>>>> skype: jpfonseka
>>>>>>
>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>*
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nuwan Dias
>>>>>
>>>>> Technical Lead - WSO2, Inc. http://wso2.com
>>>>> email : [email protected]
>>>>> Phone : +94 777 775 729
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Malintha Amarasinghe
>>>> Software Engineer
>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>> http://wso2.com/
>>>>
>>>> Mobile : +94 712383306
>>>>
>>>
>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Technical Lead - WSO2, Inc. http://wso2.com
>>> email : [email protected]
>>> Phone : +94 777 775 729
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>
>
> --
> Malintha Amarasinghe
> Software Engineer
> *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
>
>
--
--
*Joseph Fonseka*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware
mobile: +94 772 512 430
skype: jpfonseka
* <http://lk.linkedin.com/in/rumeshbandara>*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
