API Management in Azure — briefly.

We had a task to combine two big enterprise APIs. One of them was ten years old and operated based on SOAP standard, and another one was RESTfull and working with well-known logic. Of course, as soon as we understood the need of the client, we knew that Azure API management would be an accurate tool for them.

source: kutsyk.github.io

Azure API management

Here is what official docs say about it:

Use Azure API Management as a turnkey solution for publishing APIs to external and internal customers. Quickly create consistent and modern API gateways for existing back-end services hosted anywhere, secure and protect them from abuse and overuse, and get insights into usage and health. Plus, automate and scale developer onboarding to help get your API program up and running.

Briefly - Azure API management is Gateway service (Gateway API - the name of the service with similar logic in AWS).

Easiest configuration for API management is catching incoming request and transferring as it is to our backend service.
Logically the power of the service is the possibility to change the work-flow of the request - rules that control that behavior is called policies.

Policy

Here is what documentation say about them:

Policies are a powerful capability of the system that allow the publisher to change the behavior of the API through configuration. Policies are a collection of Statements that are executed sequentially on the request or response of an API. Popular Statements include format conversion from XML to JSON and call rate limiting to restrict the amount of incoming calls from a developer. Many more policies are available out of the box.

Policy expressions can be used as attribute values or text values in any of the API Management policies, unless the policy specifies otherwise. Some policies such as the Control flow and Set variable policies are based on policy expressions. For more information, see Advanced policies and Policy expressions.

Azure docs represent a bunch of working examples on how to use policies.

One of the tasks was to send an email to an administrator that the user is created, logically without touching the create user request itself.

For this, we used one-way request:

<send-one-way-request mode="new">   
<url>http://SEND_EMAIL_URI/</url>
<method>POST</method>
<set-header name=”Authorized” exists-action=”override”>
<value>{token}</value>
</set-header>
<set-body template="none">@(context.Request.Body.As<string>(preserveContent: true))</set-body>
</send-one-way-request>

So basically when API management receives the request, we send another request without caring about the result.

Of course second, most used policy from our side was catching request and sending the response from another service.

<send-request mode=”new” response-variable-name=”respVariable” timeout=”20" ignore-error=”false”>
<set-url>{SERVICE_URI}</set-url>
<set-method>POST</set-method>
<set-body template=”none”>@(context.Request.Body.As<string>(preserveContent: true))</set-body>
</send-request>
<return-response response-variable-name=”respVariable”>
<set-status code=”200" reason=”OK” />
<set-header name=”Content-Type” exists-action=”override”>
<value>application/soap+xml; charset=utf-8</value>
</set-header>
<set-body>@(((IResponse)context.Variables[“respVariable”]).Body.As<string>(preserveContent: true))</set-body>
</return-response>

This is how we used Azure API management service in our solution for merging two big enterprise APIs.

Tell me, please, in comments how you dealt with tasks of merging two APIs and managing data-flow between them.

For any questions ping me on vasyl.kutsykATgmail.com