Hi Malintha, So Basically, as an example using Rest API, if we need to get all the available tiers, it will return only the subscription tiers by below command.
curl -b cookies http://localhost:9763/publisher/site/blocks/item-add/ajax/add.jag? <http://localhost:9763/publisher/site/blocks/item-add/ajax/add.jag> action=getTiers So how can we retrieve the available tiers for application and resource level according to APIM 2.0? Thanks, On Fri, Jun 17, 2016 at 1:07 PM, Malintha Amarasinghe <[email protected]> wrote: > Hi Ushani, > > It is not included in Beta Pack. > Bdw, this feature is not used by the current throttling engine so it has > no impact on the current throttling engine. It will be only used when APIM > moves to UUF in future. So for 2.0.0 release, it is not mandatory to test > it. > > Thanks! > Malintha > > On Fri, Jun 17, 2016 at 12:40 PM, Ushani Balasooriya <[email protected]> > wrote: > >> Hi Malintha, >> >> Is this new rest api implementation is available in APIM Beta pack? If so >> we can test it. >> >> Thanks, >> Ushani >> >> On Thu, Jun 9, 2016 at 10:02 AM, Malintha Amarasinghe <[email protected] >> > wrote: >> >>> Hi All, >>> >>> I have attached the modified publisher yaml which includes new APIs for >>> the Throttling feature. Please note API level policies are renamed to >>> Advanced Policies with the new UI modifications. >>> >>> This basically contains new operations as below. >>> >>> *Application Policies* >>> GET /throttling/policies/application >>> POST /throttling/policies/application >>> DELETE /throttling/policies/application/{policyName} >>> PUT /throttling/policies/application/{policyName} >>> >>> *Subscription Policies* >>> GET /throttling/policies/subscription >>> POST /throttling/policies/subscription >>> DELETE /throttling/policies/subscription/{policyName} >>> PUT /throttling/policies/subscription/{policyName} >>> >>> *Global Policies* >>> GET /throttling/policies/global >>> POST /throttling/policies/global >>> DELETE /throttling/policies/global/{policyName} >>> PUT /throttling/policies/global/{policyName} >>> >>> *Advanced Policies* >>> GET /throttling/policies/advanced-policies >>> POST /throttling/policies/advanced-policies >>> DELETE /throttling/policies/advanced-policies/{policyName} >>> PUT /throttling/policies/advanced-policies/{policyName} >>> >>> *Blocking Conditions* >>> GET /throttling/blocking-conditions >>> POST /throttling/blocking-conditions >>> DELETE /throttling/blocking-conditions/{conditionId} >>> PUT /throttling/blocking-conditions/{conditionId} >>> >>> >>> *Few things to note:* >>> >>> 1. We define an array of Conditions in Conditional Groups when defining >>> an Advanced Policy. In implementation level, Condition is defined as a >>> parent class and its child classes are IPCondition, DateCondition, >>> HeaderCondition etc. In swagger level, the same concept is used using >>> swagger "allOf"[1] parameter to avoid the duplicated fields. >>> >>> 2. When defining a Conditional Group, the array of Conditions can be of >>> those multiple types of Conditions (defined in polymorphic way) and that is >>> also need to represented from JSON payload. >>> >>> Ex: *A sample Advanced Policy JSON object* >>> >>> { >>> "policyName": "AdvancedPolicy-1", >>> "displayName": "AdvancedPolicy-1 Description", >>> ... >>> "conditionalGroups": [ >>> { >>> "id": 0, >>> "enabled": true, >>> "description": "conditional group 1", >>> "conditions": [ >>> *{* >>> * "type": "HeaderCondition",* >>> * "invertCondition": false,* >>> * "enabled": true,* >>> * "headerName" : "Content-Type"* >>> * "headerValue" : "application/json"* >>> * },* >>> * {* >>> * "type": "QueryParameterCondition",* >>> * "invertCondition": false,* >>> * "enabled": true,* >>> * "parameterName" : "token",* >>> * "parametervalue" : "123" * >>> * }* >>> ], >>> "quotaPolicy": { >>> .. >>> } >>> } >>> ] >>> } >>> >>> From the REST API Web app, those Conditions need to be mapped to the >>> correct data type. For that @JsonSubTypes annotation was used. >>> >>> Ex: >>> >>> @JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = >>> JsonTypeInfo.As.PROPERTY, property = "type") >>> @JsonSubTypes({ >>> @JsonSubTypes.Type(value = >>> org.wso2.carbon.apimgt.rest.api.publisher.dto.DateConditionDTO.class, name >>> = "DateCondition"), >>> @JsonSubTypes.Type(value = >>> org.wso2.carbon.apimgt.rest.api.publisher.dto.HeaderConditionDTO.class, >>> name = "HeaderCondition"), >>> @JsonSubTypes.Type(value = >>> org.wso2.carbon.apimgt.rest.api.publisher.dto.QueryParameterConditionDTO.class, >>> name = "QueryParameterCondition"), >>> >>> .... >>> }) >>> @ApiModel(description = "Throttling Conditions") >>> public class ThrottleConditionDTO { >>> >>> Now CXF will now do the mapping of the JSON -> DTO correctly based to the >>> *type *field of the JSON object. >>> >>> Ex: >>> { >>> "type": "*HeaderCondition*", >>> "invertCondition": false, >>> "enabled": true, >>>>>>> >>> HeaderConditionDTO.class >>> "headerName" : "Content-Type" >>> "headerValue" : "application/json" >>> } >>> >>> >>> { >>> "type": "*QueryParameterCondition*", >>> "invertCondition": false, >>> "enabled": true, >>>>>>> >>> QueryParameterConditionDTO.class >>> "parameterName" : "token", >>> "parametervalue" : "123" >>> } >>> >>> The field specified as swagger "discriminator" [1] parameter is used to >>> specify the type field. >>> >>> Eg: >>> >>> ThrottleCondition: >>> *discriminator: type* >>> x-wso2-subtypes: >>> - DateCondition >>> - DateRangeCondition >>> - HTTPVerbCondition >>> - .... >>> title: Conditions used for Throttling >>> description: Throttling Conditions >>> required: >>> - type >>> properties: >>> type: >>> *type: string* >>> invertCondition: >>> type: boolean >>> enabled: >>> type: boolean >>> >>> >>> We did not have the capability to generate those code segments from our >>> swagger2cxf codegen tool [2] so it needed to be improved locally. Currently >>> a vendor-specific property called "x-wso2-subtypes" is used to specify the >>> subtypes which is then used to generate the above @JsonSubTypes () code >>> segment. >>> >>> Currently some of the Models shows as Warning in swagger editor as they >>> were not specifically referenced in the swagger definition. We also need a >>> way to fix it. >>> >>> Appreciate your feedback on the above implementation and the attached >>> swagger definition. >>> >>> Thanks, >>> Malintha >>> >>> [1] http://swagger.io/specification/ >>> [2] https://github.com/hevayo/swagger2cxf-maven-plugin >>> >>> On Thu, Jun 2, 2016 at 2:57 PM, Malintha Amarasinghe <[email protected] >>> > wrote: >>> >>>> Hi Shammi, >>>> >>>> Selecting the throttling tiers/policies that applies to a particular >>>> API is selected using the API Creation API [1] and it will not have major >>>> changes with this implementation. This particular API is related to the API >>>> we had early to add/remove/update tiers [2] which is an admin dashboard >>>> related functionality. >>>> >>>> With the new throttling implementation, following things have been >>>> changed, @Team, please correct me if anything need to be. >>>> >>>> 1. When creating an API earlier we select a set of Tiers which can be >>>> subscribed in store. Earlier they are called API Level tiers but now they >>>> are called Subscription Policies. Accordingly, if someone need to create >>>> such a Tier/Policy using the new REST API, he need to call *POST >>>> /throtting/policies/subscription *(please note we have not finalized >>>> the resource naming) >>>> 2. Resource level tiers and application level tiers does not have major >>>> changes with the way of applying through the UI or API. >>>> 3. However, the way Resource, Application and Subscription level >>>> policies operate has major changes compared to earlier Tiers. >>>> a. Subscription Policies are applied to Application -> API path. >>>> All users of a particular application should share the tier limit. This is >>>> similar to Application level tier early. >>>> b. Application Policies are applied to User -> Application path. So >>>> this is a per user limit. This is similar to the API Level Tiers we had >>>> early. >>>> c. Resource Level Policies are not changed in operation level but >>>> some improvements are done. They have two levels called API Level and User >>>> Level. A Resource Level Policy with API Level is similar to the earlier >>>> Resource Level Policy we had; when such tier is applied to a particular >>>> resource, all users accessing the resource will share the limit. But a >>>> Resource Level Policy with User Level is applied per User basis. >>>> >>>> For more information please see [3] where Harsha has explained this >>>> using a nice diagram. >>>> >>>> With the new implementation, there are many advantages and some of them >>>> are listed below. >>>> >>>> 1. Bandwidth based throttling; not only request count based throttling >>>> 2. Rate limiting/Burst control along with normal throttling limits >>>> 3. Support for conditional groups; eg: IP based throttling, >>>> header/query parameter based throttling/ JWT claims based throttling AND >>>> defining multiple conditions of them >>>> 4. Defining custom throttling policies using CEP Siddhi queries >>>> >>>> >>>>>> How is this going to affect on Hard Throttling Limit which came with >>>>>> AM 1.10 >>>>>> >>>>> From this implementation Hard Throttling Limits will not be affected. >>>> However in APIM 1.10.0 we did not support adding hard throttling limits >>>> from the new REST API. >>>> >>>> Thanks, >>>> Malintha >>>> >>>> [1] >>>> https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#APIsApi#apisPost >>>> [2] >>>> https://docs.wso2.com/display/AM1100/apidocs/publisher/#!/operations#TiersApi#tiersTierLevelPost >>>> [3] [Dev] [APIM] Throttling Applicability Levels With New Throttling >>>> Implementation >>>> >>>> >>>> Thanks >>>>>> Shammi >>>>>> >>>>>> On Tue, May 31, 2016 at 11:43 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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best Regards, >>>>>> >>>>>> * Shammi Jayasinghe* >>>>>> >>>>>> >>>>>> *Technical Lead* >>>>>> *WSO2, Inc.* >>>>>> *+1-812-391-7730 <%2B1-812-391-7730>* >>>>>> *+1-812-327-3505 <%2B1-812-327-3505>* >>>>>> >>>>>> *http://shammijayasinghe.blogspot.com >>>>>> <http://shammijayasinghe.blogspot.com>* >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best Regards, >>>>> >>>>> *Thilini Cooray* >>>>> Software Engineer >>>>> Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194> >>>>> E-mail : [email protected] >>>>> >>>>> WSO2 Inc. www.wso2.com >>>>> lean.enterprise.middleware >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>> >>> >> >> >> -- >> *Ushani Balasooriya* >> Senior Software Engineer - QA; >> WSO2 Inc; http://www.wso2.com/. >> Mobile; +94772636796 >> >> > > > -- > Malintha Amarasinghe > Software Engineer > *WSO2, Inc. - lean | enterprise | middleware* > http://wso2.com/ > > Mobile : +94 712383306 > -- *Ushani Balasooriya* Senior Software Engineer - QA; WSO2 Inc; http://www.wso2.com/. Mobile; +94772636796
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
