By default, your API Management instance is accessed from the internet at a public endpoint and acts as a gateway to public backends. However, APIM allows you to use an Azure virtual network to secure access to your API Management instance and to backend APIs.
One of the most incredible things about API Management is that it easily allows developers to modernize traditional or legacy APIs or encapsulate and simplify authentication mechanisms to those APIs. One of these examples is when we need to generate a token that will have an expiration time of x amount of minutes. Traditional integration processes will perform two calls each time there is a need to communicate to that API:
- The first request is to generate the token.
- The second is to perform the desired operation.
Even if there are several requests in the period that that initial token is alive, those processes simply ignore that capability because, normally it requires additional logic involved. Some more “smart” processes or applications will store that token in a cache or database, and only when the token is about to expire or has already expired will it regenerate that token.
Well, this additional logic can simply be transported to the API Management layer. To accomplish that, you can:
- Expose an “internal” method, which is token generation. That operation is responsible for checking if there is a Token in the internal APIM Cache. If it exists, return the token from the cache – avoiding an additional call to the API. If not, it will call the API to generate a new token and cache it in the internal APIM cache.
- Then, on the All Operation, the first thing, or one of the first things, you need to do is to call the “internal” token generation operation to get the token – you should perform this policy in the All operation in order to avoid reimplement this logic in each operation.
The main question is, can we implement a Self-Chained APIM request?
The answer is yes, you can. Even if your APIM service is configured to use an Azure virtual network.
You can accomplish this by using the send-request policy. The send-request policy sends the provided request to the specified URL, waiting no longer than the set timeout value.
Policy Statement:
<send-request mode="new | copy" response-variable-name="" timeout="60 sec" ignore-error
="false | true">
<set-url>request URL</set-url>
<set-method>...</set-method>
<set-header>...</set-header>
<set-body>...</set-body>
<authentication-certificate thumbprint="thumbprint" />
<proxy>...</proxy>
</send-request>
Of course, you can use the hostname of the backend URL in many cases, but you may run into specific issues if your APIM is configured to use an Azure virtual network. Now, the trick for this to always work is to change the hostname of the backend URL to https://127.0.0.1. A set-header policy should also be added to the send-request policy to add the desired host header (previously used as part of the URL).
Here is an actual sample scenario:
<policies>
<inbound>
<send-request ignore-error="false" timeout="60" response-variable-name="tokenResponse" mode="new">
<set-url>https://127.0.0.1/your-api/tokenrenewal</set-url>
<set-method>GET</set-method>
<set-header name="Ocp-Apim-Subscription-Key" exists-action="override">
<value>@(context.Request.Headers.GetValueOrDefault("Ocp-Apim-Subscription-Key", "Unknown"))</value>
</set-header>
<set-header name="Host" exists-action="override">
<value>your-gateway-host</value>
</set-header>
</send-request>
<set-variable name="tokenValue" value="@(((IResponse)context.Variables["tokenResponse"]).Body.As<string>())" />
<base />
</inbound>
<on-error>
<base />
</on-error>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
</policies>
To lazy to read? We’ve got you covered! Check out our video version of this content!
If you liked the content or found it helpful and want to help me write more content, you can buy (or help buy) my son a Star Wars Lego!
