As per discussion with Nuwan, Malintha, we have decided to go with two separate APIs as we have following challenges.
1). Even if we maintain single API for both old throttle implementation and new throttle implementation, we have to maintain different schema for each implementation as new one also include bandwidth policy define as well as complex conditions included in resource level throttling tiers. Having single API we will need to handle all of this internally within our code. Since we moving with new throttle implementation we can easily deprecate/remove the old API without major effect. 2). Because of different schema of tiers in old throttling implementation and new throttling implementation, user anyway need to change their APIs. So having single API will not enable simple switch between new implementation and with the old implementation. 3). Having two separate APIs will be more clean as tiers in old implementation is significantly differ from the new implementation. 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. > 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. > > 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 > -- Harsha Kumara Software Engineer, WSO2 Inc. Mobile: +94775505618 Blog:harshcreationz.blogspot.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
