Whats the actual use UseQuotaConfigInAPIProduct & shared quota counters

[Teja]

Hi Team,

I just going through the quota apigee docs and I found UseQuotaConfigInAPIProduct & shared quota counters concepts which are supporting in apigeex and I'm wondering what the actual use of these 2 concepts & in which scenarios have to use these.

For example the shared quota counters functionality where it needs to use second policy in ProxyEndpointResponse flow with SharedName, CountOnly, EnforceOnly elements and a step condition( In which case need to increment the counter) can also be done with the same first policy using in ProxyEndpointResponse flow with step condition right (I mean here there is no need to use second policy and that three elements). 

And what's the use of UseQuotaConfigInAPIProduct element by overwriting the actual allow, interval & timeunit elements coz if we need to change config then we'll do that directly in allow, interval & timeunit elements right without using UseQuotaConfigInAPIProduct element. If its actually configuring at product level that also we can do that directly in api product either via UI or api mgmt calls know.

I just want to check is there any specific scenarios/usecases that these new elements were introduced which can't be done in any other way with existing ones or did I understood it differently.

Thanks in advance.

[dchiesa1]

what's the use of UseQuotaConfigInAPIProduct element by overwriting the actual allow, interval & timeunit elements coz if we need to change config then we'll do that directly in allow, interval & timeunit elements right without using UseQuotaConfigInAPIProduct element.

If you use the element UseQuotaConfigInAPIProduct then you can configure the policy the same way, without regard for the name or type of the policy that enforces credential checking.

Stepping back - there are two primary policy step types that check credentials in Apigee: VerifyAPIKey and OAuthV2/VerifyAccessToken. Usually you will use one or the other of those. Sometimes the VerifyAPIKey gets combined with other steps, such as VerifyJWT or HMAC, etc. Regardless which one you use, the underlying policy logic will check various things:

• that the provided credential - a key or an oauth token - is valid. Not expired, not revoked, not belonging to an app that was revoked, nor a developer that was revoked, etc.
• that the currently executing request (eg GET /foo) is part of an API Product, for which App associated to the credential, is authorized

If these checks succeed, then the policy - VerifyAPIKey or OAuthV2/VerifyAccessToken - will set variables that describe the product, the app, the developer, any custom attributes on the above, as well as any rate limit data from the product.

The trick here is that the variable names are different between the two policies, and they also vary with the name of the credential verifying policy. So a VerifyAPIKey policy named "VerifyAPIKey-1" will set a variable named verifyapikey.VerifyAPIKey-1.apiproduct.developer.quota.limit holding the quota limit, whereas an OAuthV2/VerifyAccessToken step named "VerifyAccessToken-1" will set a variable named apiproduct.developer.quota.limit . Why is there a difference? I don't know. Historical reasons I guess. But anyway there is a difference. Therefore to use a Quota policy, you need to know which credential verifying policy you used previously, and furthermore in some cases you need to know (and hard-code) the name of the credential-verifying policy into the Quota policy configuration. That is brittle.

Further you need to set the Allow, Interval, and TimeUnit in all cases. And weirdly, the Allow element uses the countRef attribute for the variable, while the Interval element uses ref . What's up with that? It's a bunch of tricky configuration in most cases, because often people want the Quota policy to just "use what's in the API Product."

The <UseQuotaConfigInAPIProduct stepName="VerifyAPIKey-1"/> configuration element is a lot simpler; it eliminates a bunch of repetitive configuration and just makes things simpler. There's nothing you "can't do" without this element, but it's simpler with the element. And of course, you still have the option to set Allow, Interval, and TimeUnit independently.

For example the shared quota counters functionality where it needs to use second policy in ProxyEndpointResponse flow with SharedName, CountOnly, EnforceOnly elements

The CountOnly and EnforceOnly introduce new capability that was not possible before. The goal for these elements is to provide the ability to accrue against the quota bucket, based on the response that is returned from the target. For example, suppose you want to update the Quota counter if the request requires a read from storage, but not update the Quota counter if the request is returned from cache. With CountOnly and EnforceOnly, you can do that. Another scenario: the target returns a "cost" associated to the request. And you don't know how much to accrue until you get the cost from the target. So you use CountOnly in the response flow, and EnforceOnly in the request flow. This way, if an app exceeds Quota during a request, the NEXT request may be denied due to a rate limit.

It was not possible to do this, before the introduction of these new configuration elements, because the Quota policy always injects the Quota policy NAME into the quota bucket counter. So if you had two distinct policies, one to count and one to enforce, then ... you would be dealing with two distinct counters.