Hi Joe, Hi Nuwan, Yes as of now we are using the same model for all levels. Bdw we have following two attributes in the model which is specific to API tiers.
"stopOnQuotaReach": true, "tierPlan": "FREE" Would that be OK for having it for all levels? As we might be implementing this in the future? These are actually coming from the Tier implementation class. What we have done is just mapping it from Impl to DTO when it comes as the response. This will not do any harm as we are not supporting POST operation for *tiers/application* and *tiers/resource. *If we are removing them, we might have to define a different model as setting it to null is not very good looking. Thanks. Malintha On Wed, Dec 2, 2015 at 7:14 AM, Joseph Fonseka <[email protected]> wrote: > Hi Malintha > > The POST should go to /tiers/{tier-level} since if you are posting /tiers > you need to add an additional parameter. BTW is the tier model same for all > the levels ? > > Thanks > Jo > > On Tue, Dec 1, 2015 at 5:40 PM, Malintha Amarasinghe <[email protected]> > wrote: > >> 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 >> >> > > > -- > > -- > *Joseph Fonseka* > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 772 512 430 > skype: jpfonseka > > * <http://lk.linkedin.com/in/rumeshbandara>* > > > _______________________________________________ > 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
