On Thu, Jun 2, 2016 at 10:16 AM, Malintha Amarasinghe <[email protected]> wrote:
> Thanks for the responses Harsha & Jo. > > Hi Harsha, > > I think having two implementations will be enough, since we have two >> different APIs which has different resource path as well, user should aware >> which throttling implementation that they are running. Hence we might not >> need below API. Also APIM deployment can use single throttling >> implementation. >> > I was thinking it would be more convenient for clients if they can priory > know which throttling information should be used before adding/modifying > tiers/policies, as there's a possibility that Advanced Throttling can be > disabled and enabled at anytime. Please correct me if I am wrong.. > > Hi Joe, > > >> Would be helpful if you can update the Publisher API swagger and share >> then we can get a detailed idea about what are the resources and their >> schema. >> >> Sure, will update the swagger and share with you all. > > >> Is the proposed new resources are only to GET throttling configs ? if we >> are posting we need to put them in to a separate API probably called admin. >> >> The proposed schema is for all CRUD operations for throttling policies. > +1 to have a separate API (/admin) to add the new resources. Admin > dashboard is now getting improved with adding more and more functionality > and then its operations adding to publisher API is not good IMO. In future, > we will have to create a new REST API due to that. So doing it early is > better as we would otherwise have to do API changes. But as of now we only > have one resource (*/throttling*) for the new API. > > Thanks! > Malintha > > Thanks & Regards >> Jo >> >> >> >> On Wed, Jun 1, 2016 at 12:13 PM, Malintha Amarasinghe <[email protected] >> > wrote: >> >>> Hi All, >>> >>> We are going to improve the API Manager new REST API in order to support >>> the new Throttling feature of next API Manager 2.0.0. >>> >>> Earlier we had a resource */tiers/{tierLevel}* to add and retrieve >>> tiers based on API/Application and Resources. Currently a significant >>> improvements for throttling based on policies has been done and they will >>> be activated when Advanced Throttling is enabled from api-manager.xml. >>> >>> So basically we have two modes. >>> (a) When advanced throttling enabled >>> (b) Advanced throttling is not enabled. >>> >>> When advanced throttling is enabled throttling is based on >>> Policies. Policies have a new schema and they have many new fields compared >>> to earlier Tiers schema. Also Policy object is of several types (APIPolicy, >>> SubscriptionPolicy, ApplicationPolicy, GlobalPolicy) and they have >>> different fields based on the type. >>> >>> Eg: Conditional Groups in APIPolicy >>> >>> If we are going to use the same resource */tiers,* Clients can use the >>> same resource for the both cases (a) and (b). But the disadvantage is that >>> we always need to manage the same schema for the resource regardless of >>> Advanced Throttling is enabled or not (we cannot return responses with >>> different schemas for the same resource). So REST API implementation need >>> to maintain additional mappings between Tier and Policy objects and return >>> correct responses considering both cases. IMHO this makes the code >>> complicated and difficult to maintain. >>> >>> As a simple solution we can have a separate resource / >>> *throttling/policies/{policyType}* to handle new throttle >>> implementation. The downside is that the Clients/UIs need to call the >>> correct resource* /tiers/{tierLevel}* or* >>> /throtting/policies/{policyType}* based on Advanced Throttling Enabled >>> or Not. In this case client might need to send an additional request to >>> check if advanced throttling enabled or not. Based on the response, client >>> can decide either */tiers/{tierLevel} *or */throtting/policies/{policyType} >>> *should be used. >>> >>> Eg: *GET /throttling *or *GET /throttling/configuration* >>> >>> HTTP/1.1 200 OK >>> { "advancedThrottlingEnabled" : true", .. , .. } >>> >>> Any suggestion is highly appreciated. >>> >>> In an additional Note: If we use the new resource, we need to change the >>> current version of the REST API; v0.9 to v0.10. >>> >>> Thanks >>> Malintha >>> >>> -- >>> Malintha Amarasinghe >>> Software Engineer >>> *WSO2, Inc. - lean | enterprise | middleware* >>> http://wso2.com/ >>> >>> Mobile : +94 712383306 >>> >> >> >> >> -- >> >> -- >> *Joseph Fonseka* >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 772 512 430 >> skype: jpfonseka >> >> * <http://lk.linkedin.com/in/rumeshbandara>* >> >> > > > -- > 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
