Support expressions in calls attribute of rate-limit[-by-key] and quota[-by-key] policy of APIM
If the quota value can be an expression and dynamic, then it will much easier to implement dynamic quota in a single product. I want to set a per-subscription quota without create separate products for each of the subscription. Sometimes, we have requirement to increase quota for just a single subscription which force us to create a new product just for that particular user. Another case is that we want to provide capability to allow users to customize the quota value for ip/client-id throttling.
Robert Abraham commented
Regarding my suggestion below, another approach would be to define groups that are associated with a specific rate limit, and have keys be members of one defined group.
Robert Abraham commented
We are looking to rate limit IOT devices, owned by our customers, that send data to our servers. The data would be sent via REST requests, and the key that the rate limit would be applied to would likely be in a header.
We would like to be able to apply a separate rate limit per key. We don't currently have that ability with policy statements like "rate-limit-by-key", as that only allows us to assign a global rate limit per header name, rather than header value.
I can imagine a separate interface in APIM's Portal UI that allows for key management. In that interface, we'd be able to generate a new key, and define its rate limit.
Everton Macedo commented
Same here. We want to manage the quota/rate inside the user scope and not by product. It would make sense to extract this values from the user profile/claims
I support this idea. Dynamic quota policy would definitely help and easier to maintain with single product. If we have different limits for each subscription then using single product as below can solve the quota problem
<quota-by-key calls="@(context.Request.CustomCallsforKey)" renewal-period="@(context.Request.CustomRenewalPeriodforKey)"
increment-condition="@(context.Response.StatusCode >= 200 && context.Response.StatusCode < 400)"
Hi, can you tell us a little about your scenario and how this feature will help your scenario? Thanks!
Oliver Tomlinson commented
I support this.
Being able to set defined 'amounts' when creating a subscription would be great.
A Developer might initially only pay for 10 requests a second, but then at some point in the future upgrade to 20, 30 or 40 requests a second.
Yes we could achieve this right now by having 5 different products, but this would mean the developer would have to reintegrate against the API with the new ocp-apim-subscription-key which is a bad experience for the developer.
Maybe the real answer here is to be able to migrate a subscription to a different products and preserve the ocp-apim-subscription-key?