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
