Next & Previous

Azure API Management

API Settings

I’m looking into Azure API Management (APIM) to find out how I can wrap my contemporary WCF services from the previous post.


Make the resource

I made a new Azure API Management service resource in the Azure portal.

Import APIs via OpenAPI/Swagger/WSDL

I added my APIs using their Swagger defintions (aka OpenAPI), found at for example. I had to clean up the def from Locations because, as discussed in the previous post, it had traces of its sibling API in there - still an unsolved problem. It probably would have been easier to use SOAP WSDLs instead since they have both!

In the Settings tab, I had to give each service a different ‘API URL Suffix’, and went with location and order.

I created a Product, “TacoGong”, added both APIs to it, and Published it (making it live)

Set backend service URL

In the Test window, the LocationService API wouldn’t work. By switching to the Trace tab, I found that the ‘Backend URL was not set’. So in the API Design tab, I had to set the URL override like this:

Setting the URL override

I think this was because of my messed up Swagger def. This window wouldn’t let me switch to ‘Azure resource’ which was weird. I don’t really know what’s going on with this process and why I have to do this step.

Test GET

I used the test tools to see that the Location APIs now worked, and because they’re simple GET points, you can go straight to them in browser: (if it’s still live).

You can see that the APIM URL is a lot nicer than the WCF one with its .svc irregularities and gives the same result:

URL comparison

For accessibility, here are the two URLs from the image above:

Old URL:
New URL:


For completeness, here’s a demo of hitting the original POST endpoint and its new APIM moniker:

Old POST URL in Postman

New POST URL in Postman

Old URL:
New URL:


APIM was pretty easy to set up, despite a few snags, and worked a treat for this simple scenario. This doesn’t go into the other powerful features of APIM like transforming requests/responses, and API versioning. But it’s a start, and a big improvement to a WCF estate.