Are there valid use cases where we may need to apply different quota limits on proxies bundled in a single API product? Or is it recommended practise to create a product per proxy to achieve this?
We are also looking to apply quota policies at resource level and method level for each resource. What would be the best approach for this ? Thank you.
Solved! Go to Solution.
Are there valid use cases where we may need to apply different quota limits on proxies bundled in a single API product?
Possibly there are valid use cases. I don't know what they might be though...
There are ways to achieve per-proxy quotas.
Today the quota limit defined on an API Product is a single quota number.
How it works at runtime:
If you want to apply a different limit for each proxy in a product, you can do that. The way to do it:
define custom attributes on the API product representing the quota limit for each proxy. For example
custom attr name | value | meaning |
proxy1 | 100 | quota limit for proxy1 |
proxy2 | 1200 | quota limit for proxy2 |
We are also looking to apply quota policies at resource level and method level for each resource.
If you want to do something more elaborate, then I'd suggest externalizing the quota limits on the per-resource or per-method basis into a JSON or other data format. You could attach that as a custom attribute to the API product too.
Then you would need to run a little JavaScript step that performs a JSON.parse() on that value, and then sets the appropriate context variables for the given resouce path and verb (etc) by examining request.verb, proxy.pathsuffix, and comparing that against what is in the JSON blob.
Set variables like "quota_limit" and then invoke the Quota policy using that variable.
@Sarah If you want to put different constant quota values for each proxy then you can set your quota at proxy as literals instead of reference values. If you want in reference, then you can set custom attributes at developer app, developer or product level for the different quotas, then after API key verification, you can use those in quota policy of different proxies as reference.
Are there valid use cases where we may need to apply different quota limits on proxies bundled in a single API product?
Possibly there are valid use cases. I don't know what they might be though...
There are ways to achieve per-proxy quotas.
Today the quota limit defined on an API Product is a single quota number.
How it works at runtime:
If you want to apply a different limit for each proxy in a product, you can do that. The way to do it:
define custom attributes on the API product representing the quota limit for each proxy. For example
custom attr name | value | meaning |
proxy1 | 100 | quota limit for proxy1 |
proxy2 | 1200 | quota limit for proxy2 |
We are also looking to apply quota policies at resource level and method level for each resource.
If you want to do something more elaborate, then I'd suggest externalizing the quota limits on the per-resource or per-method basis into a JSON or other data format. You could attach that as a custom attribute to the API product too.
Then you would need to run a little JavaScript step that performs a JSON.parse() on that value, and then sets the appropriate context variables for the given resouce path and verb (etc) by examining request.verb, proxy.pathsuffix, and comparing that against what is in the JSON blob.
Set variables like "quota_limit" and then invoke the Quota policy using that variable.
Thank you for the detailed answer!
@Sarah If you want to put different constant quota values for each proxy then you can set your quota at proxy as literals instead of reference values. If you want in reference, then you can set custom attributes at developer app, developer or product level for the different quotas, then after API key verification, you can use those in quota policy of different proxies as reference.