Skip to main content

Azure API Management - Your back-end api (Part 2)


(Alternate Title) Build Test Deploy your NodeJS app on Azure Cloud using Azure DevOps


This is part 2 of a series of posts where I will be talking about exposing your back-end apis via Azure API Management as production ready apis.

In this post I will discuss a sample scenario that we will use throughout this series to explore the capabilities of the platform. 

In this post we will:

  1. Start with a sample scenario
  2. Look at the APIs we will later be exposing via APIm
  3. Have an swagger file that defines our api endpoints
  4. Run our app locally
  5. Use Postman to test out our app's API endpoints
  6. Explore the unit tests written for our app
  7. Setup an ALM pipeline using Azure DevOps
    1. Build our app & run unit tests using Azure DevOps
    2. Use Azure CLI to create an App Service to deploy our app
    3. Use Azure Devops to deploy your app

Lets look at the following sample scenario then ...

1. Sample Scenario

The sample app for this scenario exposes a RESTful {:/movie} endpoint. The app has been written using node.js & before we expose the app via APIm, we need to:
  1. run the app locally& understand all APIs being exposed
  2. write some test postman scripts that help us test the application

The code for the sample scenario is available at

The code written for this post has been forked & modified from Samuele Zaza's original repo (if you are interested in the code, Sam has written an excellent post detailing how to build the application.).

2. The APIs we will later expose using APIm

The app itself exposes the following API endpoints: 

3. Our API Definitions

This app can be considered as a "Back-End-Service" that you are planning to expose. As a port of creating the above app, we have created a swagger API definition.

The API definition is accessible at (Note: If you have created your own API, you will need this link before the next step.)

4. Running your App

The instructions to run the app are available within the readme of the repo. After successfully running the app, you should now be able to query the swagger file via the /swagger endpoint [http://localhost:10010/swagger] like so ..

5. Using Postman With Swagger to test your API

We can now use postman to import the swagger definition and generate all the available endpoints that are exposed by this app. You can do it like so ..

Open postman & click the import button like so ..

Click the "import from link" button and enter the url endpoint for the /swagger file like so ..

You should now be able to see a newly imported collection "the RESTful movies app". I encourage you now to try each of the exposed endpoints like so ..

6. Explore the unit tests written for our app

Although this part is not required, I've also showcased how to run all our unit/integration tests locally like so ..

We will be running these tests later on as a part of our ALM (build-test-deploy) pipeline.

7. Setup an ALM pipeline using Azure DevOps

In this section we will setup a complete ALM pipeline on the Azure cloud, and use Azure DevOps to build, test & deploy our application.

7.1 Build & Test your App

You can create a new Azure DevOps account for free at the following link []. Although you can use other tools to accomplish this, I wanted to use Azure Devops as its free AND is super easy to setup something very quickly (even though my repo is hosted in github).

Within your Azure DevOps account you need to start by creating a new Project like so ..

Next you need to start by creating a new Pipeline to build & test the App. This build pipeline will now create necessary build artefacts later used to deploy your application. To do so, start by clicking Pipelines, then Builds, click New & follow these steps ..

You now have an application with an integrated Building & Testing capabilities.

7.2 Use Azure CLI to create an App Service to deploy our app

The reason I've added this section is so that we can leverage Azure CLI to also create our API portal later in the series.

I have used the following post to guide me in deploying this app: "Create a web app and deploy files with FTP".

The Azure CLI is Microsoft's cross-platform command-line experience for managing Azure resources. You can use it in your browser with Azure Cloud Shell, or install it on macOS, Linux, or Windows and run it from the command line.

Before you're able to deploy your WebApp, you need to:

  1. Start by creating an Azure account. You can create one for free at
  2. Download and install the Azure CLI toolset (you can get it here)
  3. Choose the name of a resource group where you'll deploy your application (in my case i'm creating a new one called rg-ause-movie-collection)
  4. Choose a deployment location (i'll be deploying to the Australia Southeast data center)
  5. Choose an App Service Plan & the tier (i'm creating an app service plan named rg-ause-appsvcplan-free in using the free tier)
  6. Pick a name for your web application (i'm calling it rg-ause-webapp-movie-collection)
  7. Select the appropriate NodeJS version (you can check available runtimes using az webapp list-runtimes)
Once you've made these decision, the steps to create your Web App are detailed at

7.3 Use Azure Devops to deploy your app

Now that your app has been built, your code tested & the necessary build artefacts published to Azure DevOps, we can now deploy the artefacts to the App Service created in the previous section.

Similar to the previous section, we will again be leveraging the ease of deployment in Azure Devops. The detailed steps & screenshots are available at

After completing these steps, your will have the ability to deploy your app after every successful checkin.

I will be writing a series of posts to cover this topic, stay tuned ..

- Part 1: Azure API Management - An introduction
- Part 2: Azure API Management - Your back-end api
- Part 3: Azure API Management - Creating a gateway & exposing your api
- Part 4: Azure API Management - Add rate limiting & consuming the api
- Part 5: Azure API Management - Add security
- Part 6: Azure API Management - Using REST APIs to manage your APIm (using postman)
- Part 7: Azure API Management - Auto-publish your APIs to APIm using Azure DevOps, Postman & Newman


Popular posts from this blog

Internet Information Services(IIS) reveals its real or internal IP Address

In the ever changing world of global data communications, inexpensive Internet connections, and fast-paced software development, security is becoming more and more of an issue. Security is now a basic requirement because global computing is inherently insecure.

Keeping that in mind, we recently ran our flagship product through a security audit. It was such a helpful exercise in tying-off any remaining lose ends in our application in terms of application security. 
Based on the security audit report, there was a relatively minor issue that appeared when accessing the /images directory of our application. Turns out that the Location response header of the 301 request returns an Internal IP address. The issue is detailed below.

Issue reportedInternet Information Services (IIS) may reveal its real or internal IP address in the Location header via a request to the /images directory. The value returned whilst pen testing is

The riskInformation regarding internal IP add…

IIS Request Filtering to block HTTP Verbs (For example Trace)

The issueRequest Filtering is a built-in security feature that was introduced in Internet Information Services (IIS) 7.0. This can be used to block specific verbs like "Trace".

When request filtering blocks an HTTP request, IIS 7 will return an HTTP 404 error to the client and log the HTTP status with a unique substatus that identifies the reason that the request was denied. Verb Denied.

HTTP SubstatusDescription404.5URL Sequence Denied404.6Verb Denied404.7File Extension Denied404.8Hidden Namespace404.1Request Header Too Long404.11URL Double Escaped404.12URL Has High Bit Chars404.13Content Length Too Large

Unit Testing HttpContext.Current.Session in MVC3 .NET

We recently changed some functionality where during the "CREATE" process, we go through a wizard to save application data. This data is saved only to the session in the final step when the user clicks the final submit.

This was easy enough to implement but when I started writing unit tests for my static methods that Add, Update, Delete or Modify the contents of our application data in the session, I got the following error:
System.NullReferenceException: Object reference not set to an instance of an object.

Turns out I had forgotten to setup the HttpContext.
The following "TestInitialise" method fixed my problem :)

public void TestSetup()
// We need to setup the Current HTTP Context as follows:

// Step 1: Setup the HTTP Request
var httpRequest = new HttpRequest("", "http://localhost/", "");

// Step 2: Setup the HTTP Response
var httpResponce = new HttpResponse(new StringWriter());

// Step 3: Se…