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
