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
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
