Hi
I don't know why but it looks like you have two entirely different questions in that post, including the "hi/hello" greeting part, concatenated together with a comma. How does this happen? Any ideas? I've seen this before. Are you typing the same story twice, for some reason, and wording it differently? And when you posted the question, why didn't you see that your question text was duplicated? I guess if you saw the duplication you would click the "Edit" button and fix it. I regularly see this situation, and it puzzles me.
OK, now to answer the question. The Quota policy uses an Identifier. Think of the identifier as the name on the quota counter. You can choose, by setting the identifier in the Quota policy, to have different counters. You can choose how the counters get applied. Some implications:
-
If you specify an identifier of a constant string, like "ABC",
<Quota name="Q1" type='flexi'>
<Interval>1</Interval>
<TimeUnit>minute</TimeUnit>
<Allow count='1000'/>
<Identifier>ABC</Identifier>
</Quota>
...then, that single counter will be used everywhere. API calls arriving from any device, any user, any app written by any developer, every API key in those apps, and so on.
If you then apply different quota policies in your API proxy with Identifier "ABC" then, there is just one single counter, globally. If the limit is 1000/minute, then every API call from any app/user/developer.... gets counted within that 1000/minute.
-
If you specify an identifier with a reference to the context variable "developer.id",
<Quota name="Q1" type='flexi'>
<Interval>1</Interval>
<TimeUnit>minute</TimeUnit>
<Allow count='1000'/>
<Identifier ref="developer.id"/>
</Quota>
...then call counts of inbound API requests from any device, any user, any app written, and any API key in those apps, will be
grouped by developer, and each of those groups will be counted under a distinct bucket. If you have 768 apps written by 10 different developers, and those apps are used across 1 million users, then you will have exactly 10 different quota counters, globally.
-
If you specify an identifier that refers to the client_id (aka API Key, aka Consumer ID,
<Quota name="Q1" type='flexi'>
<Interval>1</Interval>
<TimeUnit>minute</TimeUnit>
<Allow count='1000'/>
<Identifier ref="client_id"/>
</Quota>
...then, counts of inbound requests will be grouped by API KEY. If a single developer has embedded one particular API Key into the iOS version of the app, and then another API Key into the android version of the app, then you will have 2 counters, while there may be 100,000 instances of the app running, with 100,000 distinct end users.
-
Suppose you use OAuth2 (highly recommended) and specify an identifier that refers to the token
<Quota name="Q1" type='flexi'>
<Interval>1</Interval>
<TimeUnit>minute</TimeUnit>
<Allow count='1000'/>
<Identifier ref="access_token"/>
</Quota>
...then, counts of inbound requests will be grouped by token. Tokens are unique strings for each instance of each app. Therefore if you have 100,000 instances of the app running for unique end-users, you will have 100,000 quota counters. Each individual instance will get its own quota counter.
The Quota can be applied at different levels. There may be good reason for you to chain several Quota policies in series - one that uses a developer.id, and another that uses access_token.
Keep in mind the edge cases. For example, suppose the developer of the app is aware that quotas are enforced by "access_token". In that case, when the app receives a 429 (Too Many Requests) from a Quota enforcement, the app may respond by requesting a new token, and using the new token in a subsequent request. In that case, the app implicitly gets a new quota counter. So if you're not careful, a Quota enforced using access_token as the Identifier may just result in more requests for tokens, without actually enforcing any real limits in practice. The solution to THAT problem may be a quota enforcement (with a different identifier!) on the token dispensing endpoint.
LinkedIn
Twitter
