I am not sure what problem you're solving. Maybe let's just talk a little about Quota policies, to help clarify things.
The Quota policy allows you to refer to the {allow, timeunit, and interval} via variable references.
<Quota name='Quota-1'>
<Identifier ref='my-identifier' />
<Allow countRef='allow_limit' count='1000'/>
<Interval ref='quota_interval'>1</Interval>
<TimeUnit ref='quota_timeunit'>minute</TimeUnit>
</Quota>
It always confounded me that two of those elements use ref= and the other uses countRef=. smh. But anyway, the fact that you can refer to variables there means these things are dynamic. They are determined at runtime. As an example, if at runtime the allow_limit variable is 500, the timeunit is unset, and the quota_interval value is 10, that means this Quota policy will allow 500 calls every 10 minutes. The two variables that are set override the hard-coded values in the Quota policy configuration.
The App and the Product are different types of entities in the Apigee configuration model. You can attach metadata to those entities, and that data is then available at runtime, after your API Proxy has validated a credential (key or token). If you want an App-driven Quota, then you can attach the {allow, timeunit, interval} values to the App via custom attributes, and then refer to those dynamic values in the Quota policy configuration. If you want a Quota that is driven by metadata stored at the Product level, then you can do the analogous thing with API Product custom attributes.
You can also simplify things, and just omit the "Interval" if your case is simple and you always enforce a quota for an interval of 1. one hour, one minute, one day. That means less metadata to store on the App or Product. Then you need to store only the allow and timeunit values. If your quotas are always "by the hour" then you can further simplify things and store only the allow value. But this "simplification" will introduce some inflexibility; if you later decide to have different timeunits or different intervals, you will need to update the proxy to accommodate that.
Now let me address some of your specific comments.
if i set the limit at APP level which is at APP 1 of 500 calls per minute then all three products will have the same limit .
That's not the way I think about it. If you set the quota metadata on the App, then... you will have quota metadata on the App, and not on the product. The API Products will not have quota metadata. The API Product will have nothing to say about the Quota behavior. That's just how it would work. If you want Product-based rate limits, then you can't attach the rate limit metadata to the App. That's the wrong place.
If i set the limit at the Product level for my APP 2 then my Product 2 will have two different quota policies .
Suppose App 2 invokes an API, which is handled by Apigee. App 2 sends in its credential (API Key or token). When your API proxy verifies the credential (VerifyAPIKey or OauthV2/VerifyAccessToken), it will resolve to exactly 1 API Product. It does not matter that App 2's credential is authorized for 3 products. At runtime, based on the API proxy that handles the call, Apigee will select exactly 1 API Product and will perform the authorization check based on that API Product. Apigee will also retrieve the metadata for that specific API Product, including quota-related metadata, if you have stored any for the product. Then if you have a Quota policy in the API Proxy, it can refer to that retrieved metadata.
Because Apigee selects exactly 1 API Product for authorization at runtime, it is a bad idea to configure a single API Proxy into multiple API products, and then authorize a single App on those multiple API Products. If you do this, then the behavior of Apigee in selecting an API Product at runtime will be "undefined". This leads to uncertainty as to which API Product metadata gets loaded, and of course how your Quota policy might behave. So don't do that.
...my Product 2 will have two different quota policies
Products don't get Quota policies. You can set Quota metadata on Products, but you are limited to set exactly one set of {allow, interval, timeunit} on an API Product. There is also the recently-added option in API Products, available if you are using Apigee X or hybrid, to allow setting of {allow, interval, timeunit} on each REST Operation, or on each GraphQL operation. But even here, the same principle applies - there is only metadata stored at the product level. There is no _policy_ stored at the product level. In Apigee, the term "Policy" refers to a specific, well-defined thing. The point is, you cannot attach a Policy to a Product.
You attach policies, including things like Quota policies, to Proxies. So, with Apigee, it is never correct to say "My product will have a quota policy." It is not correct to say "my product will have two different quota policies." That doesn't make sense. That's not how it works.
LinkedIn
Twitter
