Hi Frank,
/tiers/{tier-level} is a collection. Using "api", "application" or
"resource" for {tier-level} parameter, we can retrieve the collections of
API, application or resource level tiers. We decided to use
/tiers/{tier-level} because in APIM itself they are maintained separately.
I.e. we have 3 separate files in registry to store API, Application and
Resource level tiers. We use POST tiers/{tier-level} to add tiers for each
collection.
Thank you,
Malintha
On Sat, Dec 12, 2015 at 3:59 PM, Frank Leymann <[email protected]> wrote:
> Hi Malintha,
>
> sorry for the late response. A post is used on a collection to add a new
> resource to this collection. While /tiers is for sure a collection, the
> question is whether /tiers/{tier-level} is a collection too. Even if it
> is, it sounds a bit strange to me to add a tier to a collection that
> corresponds to a tier-level.
>
> Instead, I assume that the data model of a tier contains more than just a
> tier-level attribute, right? If tier-level is one of many properties of a
> tier, I suggest that we POST to /tier...
>
>
> Best regards,
> Frank
>
> 2015-12-01 13:10 GMT+01:00 Malintha Amarasinghe <[email protected]>:
>
>> 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
>>
>
>
--
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
