Hi,
Another option is using a combined id. Ex: /tiers/{group}-{tiername}. That
is similar for the {provider}-{api}-{version} parameter we used for
identifying an API.
Thanks.
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
>
--
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
