If you are using Azure API management service to federate access to your backend APIs, then you’ve faced the requirement to automate how to deploy those APIs to it, in this post I show you how we achieved this at my current company.

The Scope

The goals we want to achieve are:

• Automating API operation, request, and response (API schema in general) creations from one swagger file.

• Configuring things like redirect, caching, validation …etc policies for each API operation.

The first step is not hard to automate, there are some existing options available to automate it, few of those include for example the Az DevOps extension created by Stephane Eyskens. Microsoft offers a resource kit to manage and automate your API gateway deployment.

The main shortcomings of the solution I came across are either its complexity (The Microsoft one) or the lack of support for defining API policies on a granular level.

The Solution

For us, our API development process starts with creating a swagger document file for the API, and we treat it as technical documentation for the API, API management has support for importing and creating an API from a swagger file (v2 or v3), with one limitation being the lack of support for defining API or operation policies in the same swagger file. Part of the solution came to me while reading how aws API gateway handles authorization, it provides pre-defined extensions to the open API spec that customizes the behavior of the gateway. We are going to follow the aws example and define our own open API spec extension x-az-policy that will hold the API or operation policies.

Show Me the code

The source code that accompanies this blog is hosted here, most of the interesting code is defined under AzureApiManagementApiComponent.cs file, this defines the pulumi component that reads the swagger input and translate it to Azure API management constructs. The component starts by receiving initialization parameters and setting some private state

the next step is to parse the swagger file into a strongly typed representation, for that, I’m using the OpenAPI.NET SDK to parse the swagger file.

From there we start by creating the top-level API first

Our design allows having policies defined at the API level, after creating the API we check if the API has any policy statement defined using our custom extension this reads the extensions defined at the API levels and creates an ApiPolicy resource and attaches it to the created API definition. keep in mind that we are expecting to see valid Xml API management policies defined so we don’t validate the input here.

The next step in our code involves adding the schema with all type definitions to the API, the code for that looks like this below:

As we now have our schemas created we can move to create the individual API operations, I will skip showing the detailed code for this part, a pseudo code for the process will look like:

at this step, we have our API fully created, including all of its operations and the schemes for request and responses, and we can add the defined policies at the API operation level:

With this, we get the last resource we need for our API created and defined on the Azure API management service.