Creating different products using single proxy.

Not applicable

I want to create three different products based on quota policy conditions that are to be applied on a single proxy.

For example:

1st product should handle 100 requests per day.

2nd product should handle 200 requests per day.

3rd product should handle 300 requests per day.

Is it even possible?

Solved Solved
0 3 564
1 ACCEPTED SOLUTION

Here's how it works. First, let's start with some basics. The API Proxy is the artifact that captures the instructions for what should run, when an inbound request is made. The API proxy is bound to a basepath, For example Proxy1 may have basepath=/foo/bar. This means that any request arriving at basepath /foo/bar will be routed to Proxy1 and the instructions (or policy steps) configured there will run.

ONE of the steps that can be configured for an API proxy is a Quota enforcement policy. Enforcing a quota is entirely optional, but if you add a Quota enforcement policy to a proxy, Apigee Edge will enforce the quota.

The API Product is just a way to associated metadata to an API Proxy, and then expose it to "consumer" developers - people building against the API. The metadata for the API Product includes quota limits, as well as lots of other things.

Question 1: When a Quota policy is included in a Proxy, What quota is enforced?

In Apigee Edge, the Quota policy can use a hard-coded value for the maximum count, or can refer to a variable for the value of the maximum count. If you wish to use product-specified quota values, then you need to use the latter, the variable. In XML configuration, it looks like this:

<Quota name="Quota-1">
    <!-- works with VerifyAccessToken -->
    <Identifier ref="access_token"/>
    <Allow countRef="apiproduct.developer.quota.limit" count="0"/>
    <Interval ref="apiproduct.developer.quota.interval"></Interval>
    <TimeUnit ref="apiproduct.developer.quota.timeunit"></TimeUnit>
    <Distributed>true</Distributed>
    <PreciseAtSecondsLevel>false</PreciseAtSecondsLevel>
    <Synchronous>false</Synchronous>
</Quota>

All those "ref" attributes refer to variables, also known as context variables, that will be set at runtime in the context of the message being processed. As indicated by the names, these variables hold data from the API Product. OK, great.

Question 2: how do the variables get populated???

Variables get filled with the appropriate data from the API Product, when a VerifyApiKey policy is enforced, or when an OAuthV2/VerifyAccessToken policy runs. Frustratingly, the set of variables is DIFFERENT for these different policies. For more on this, see THIS for VerifyApiKey, and THIS for VerifyAccessToken.

This means that, in order to use a Quota that refers to data configured for the product, the inbound call must FIRST be authenticated with a key or token associated to the API Product. Do you follow? There must be two policies: VerifyApiKey + Quota, or VerifyAccessToken + Quota.

Question 3: how can you, as an API publisher, associate a key or token to an API Product?

Configure the API product as you normally would. You must add in the API proxy to the API product. Save it. Then, Create a Developer App. (You may need to create a developer first). When you create the developer app, select an API Product. Click Save, and the API Key (aka consumer key) created there will associated to the API product you selected.

If you then create an additional developer app, you can choose a different API Product. You will get a different API Key (consumer key).

Putting it All Together

Create an API Proxy. Choose a basepath for the API Proxy. Add a policy into the preflow: VerifyApiKey. Configure it like this:

<VerifyAPIKey name="VerifyApiKey-1">
  <DisplayName>Verify API Key</DisplayName>
  <APIKey ref="request.header.apikey"/>
</VerifyAPIKey>

Add a second policy into the preflow, Quota. Configure it like this:

<Quota name='Quota-1'>
  <Identifier ref='request.header.apikey' />
  <!-- the count specified is used unless overridden by the variable referenced here -->
  <Allow countRef='verifyapikey.VerifyApiKey-1.apiproduct.developer.quota.limit' count='1000'/>
  <!-- use the interval in the variable; if not present use the value specified here. -->
  <Interval ref='verifyapikey.VerifyApiKey-1.apiproduct.developer.quota.interval'>1</Interval>
  <!-- use the timeunit provided in the variable; if not present use the value specified here. -->
  <TimeUnit ref='verifyapikey.VerifyApiKey-1.apiproduct.developer.quota.timeunit'>hour</TimeUnit>
  <Distributed>true</Distributed>
  <Synchronous>false</Synchronous>
  <PreciseAtSecondsLevel>false</PreciseAtSecondsLevel>
</Quota>

Create two API Products, with different quotas. Include the API proxy you just created into each one.

Create two Developer apps, each one associated to one of the API products.

If you then invoke the same API proxy, two different times, once with the first API key, and once with the second, and view the transactions in the Edge trace tool, you will see that different context variables get set for holding the quota. Different quotas get enforced.

Apigeek @Stephen Gilson explains the basics of the quota policy in depth, in this 4-minute video.

And there's a followup of that video, explaining how to use multiple API Products, in this video.

The second video explains the role of API Products, and how to get the Quota to enforce the limits specified in the API product.

View solution in original post

3 REPLIES 3

Yes, It's possible. Have you tried ? Do you see any issues ?

I have a doubt..

if we are using a single proxy, how and where do I put these condition of concurrent rate policy as well as quota policy, so that it gets redirected to respective products.

Here's how it works. First, let's start with some basics. The API Proxy is the artifact that captures the instructions for what should run, when an inbound request is made. The API proxy is bound to a basepath, For example Proxy1 may have basepath=/foo/bar. This means that any request arriving at basepath /foo/bar will be routed to Proxy1 and the instructions (or policy steps) configured there will run.

ONE of the steps that can be configured for an API proxy is a Quota enforcement policy. Enforcing a quota is entirely optional, but if you add a Quota enforcement policy to a proxy, Apigee Edge will enforce the quota.

The API Product is just a way to associated metadata to an API Proxy, and then expose it to "consumer" developers - people building against the API. The metadata for the API Product includes quota limits, as well as lots of other things.

Question 1: When a Quota policy is included in a Proxy, What quota is enforced?

In Apigee Edge, the Quota policy can use a hard-coded value for the maximum count, or can refer to a variable for the value of the maximum count. If you wish to use product-specified quota values, then you need to use the latter, the variable. In XML configuration, it looks like this:

<Quota name="Quota-1">
    <!-- works with VerifyAccessToken -->
    <Identifier ref="access_token"/>
    <Allow countRef="apiproduct.developer.quota.limit" count="0"/>
    <Interval ref="apiproduct.developer.quota.interval"></Interval>
    <TimeUnit ref="apiproduct.developer.quota.timeunit"></TimeUnit>
    <Distributed>true</Distributed>
    <PreciseAtSecondsLevel>false</PreciseAtSecondsLevel>
    <Synchronous>false</Synchronous>
</Quota>

All those "ref" attributes refer to variables, also known as context variables, that will be set at runtime in the context of the message being processed. As indicated by the names, these variables hold data from the API Product. OK, great.

Question 2: how do the variables get populated???

Variables get filled with the appropriate data from the API Product, when a VerifyApiKey policy is enforced, or when an OAuthV2/VerifyAccessToken policy runs. Frustratingly, the set of variables is DIFFERENT for these different policies. For more on this, see THIS for VerifyApiKey, and THIS for VerifyAccessToken.

This means that, in order to use a Quota that refers to data configured for the product, the inbound call must FIRST be authenticated with a key or token associated to the API Product. Do you follow? There must be two policies: VerifyApiKey + Quota, or VerifyAccessToken + Quota.

Question 3: how can you, as an API publisher, associate a key or token to an API Product?

Configure the API product as you normally would. You must add in the API proxy to the API product. Save it. Then, Create a Developer App. (You may need to create a developer first). When you create the developer app, select an API Product. Click Save, and the API Key (aka consumer key) created there will associated to the API product you selected.

If you then create an additional developer app, you can choose a different API Product. You will get a different API Key (consumer key).

Putting it All Together

Create an API Proxy. Choose a basepath for the API Proxy. Add a policy into the preflow: VerifyApiKey. Configure it like this:

<VerifyAPIKey name="VerifyApiKey-1">
  <DisplayName>Verify API Key</DisplayName>
  <APIKey ref="request.header.apikey"/>
</VerifyAPIKey>

Add a second policy into the preflow, Quota. Configure it like this:

<Quota name='Quota-1'>
  <Identifier ref='request.header.apikey' />
  <!-- the count specified is used unless overridden by the variable referenced here -->
  <Allow countRef='verifyapikey.VerifyApiKey-1.apiproduct.developer.quota.limit' count='1000'/>
  <!-- use the interval in the variable; if not present use the value specified here. -->
  <Interval ref='verifyapikey.VerifyApiKey-1.apiproduct.developer.quota.interval'>1</Interval>
  <!-- use the timeunit provided in the variable; if not present use the value specified here. -->
  <TimeUnit ref='verifyapikey.VerifyApiKey-1.apiproduct.developer.quota.timeunit'>hour</TimeUnit>
  <Distributed>true</Distributed>
  <Synchronous>false</Synchronous>
  <PreciseAtSecondsLevel>false</PreciseAtSecondsLevel>
</Quota>

Create two API Products, with different quotas. Include the API proxy you just created into each one.

Create two Developer apps, each one associated to one of the API products.

If you then invoke the same API proxy, two different times, once with the first API key, and once with the second, and view the transactions in the Edge trace tool, you will see that different context variables get set for holding the quota. Different quotas get enforced.

Apigeek @Stephen Gilson explains the basics of the quota policy in depth, in this 4-minute video.

And there's a followup of that video, explaining how to use multiple API Products, in this video.

The second video explains the role of API Products, and how to get the Quota to enforce the limits specified in the API product.