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