Skip to main content

Azure API Management - Creating a gateway & exposing your api (Part 3)


Introduction

This is part 3 of a series of blog posts where I will be talking about creating an Azure API Management gateway to expose a "back-end service".

In the last post I discussed a sample back-end service that we created. From the last post we now have an API definition which we can use in this post to create a gateway & expose our api. 

The url of the API definition as discussed in the last post is https://raw.githubusercontent.com/rohit-lakhanpal/azure-api-mgt-resources/master/swagger.json).

Ok then lets setup our gateway now.


Setting up an Azure API Management Gateway


Step 1: You need a resource group

To begin with you will need to create a resource group. The "back-end" service we created in the previous post will ideally be in the same resource group. 

Creating one is simple enough. Start by clicking the + icon on your azure portal & then simply follow the prompts as shown in the screenshots below:





Step 2: Add API Management to your Resource Group

To do this, navigate to the newly created resource groups & click on "Overview". You then need to click the [+ Add] icon & search for API Management. For the rest simply follow the creation wizard as shown in the screenshots below.











Once created, you should now be able to see the API Management gateway in your resource group. Click on the gateway & navigate to the overview. You should now be able to access the "Publisher" & "Developer" Portal.





Step 3: Navigating the publisher portal

As shown in the image above, open the publisher portal by clicking the "Publisher portal" link. This should open the portal in a new window which should look something like this ..

The homepage shows the dashboard view of all your apis.


When you click the "API" nav menu, it shows all available APIs. By default, an "Echo API" gets created for you. Whilst we will not be using it, lets look at all the options & settings for the echo api.
Now click the "Echo API" link

You should now be able to see the Summary page for the Echo API. As you can see, no calls have been made to the api at the moment.

The settings page lets you configure some basic details.

This is an important page. This shows all permitted operations for our api. From the screenshot above you can see that this api allows the following HTTP request methods:
GET, POST, PUT, DELETE, HEAD

API security can be set on this tab.

The "Issues" tab shows any issues that have been reported by the API's subscribers.

Now before we look at the "Products" tab, lets understand what products are & what they do?

Step 4: Understanding products

When you create any API in the portal, you can assign the API to one or many products. These products help set the the following properties to an api:
  • You can set/restrict the visibility of an API (if you need to be a registered developer on the developer portal)
  • Set weather a user is automatically appoved to use the API or requires administrator approval
  • Allow simultaneous multiple subscriptions
  • Specify which groups of users can view the API
  • List existing subscribers of an API
Now lets navigate to the products page by clicking the "Products" nav menu item.




As you can see here, the API comes built with 2 types of products; Starter & Unlimited. Lets look at the differences between the 2 products:

   Starter Unlimited
Description Subscribers will be able to run 5 calls/minute up to a maximum of 100 calls/week.  Subscribers have completely unlimited access to the API. Administrator approval is required.
Requires subscription Yes Yes
Requires subscription approval No Yes
Allows multiple simultaneous subscriptions  No No
Groups enabled to view and subscribe for this product Administrators
Developers
Guests
Administrators
Developers
Guests
Quota 100 calls per 7 days None
Rate Limit 5 calls per minute None

Now that you know the differences, lets have a look at the "Products page for the "Echo API"


This "Echo API" has both product offerings. It means that when developers sign up to the portal, they will be able to choose which product offering to which they wish to subscribe. (You will understand this better when you have a look at how to call these APIs. I will be discussing this in part 4).

Now that you've see what the Echo API is capable of, lets add our back-end APIs to this gateway.

Step 4: Add your APIs to the gateway

Now that we've had a look at the Echo API, we can import the API definition that we had created earlier as shown below. All we need is the API definition file we created using Swagger (from part 2). 

Click the "Import API" link

Select the options to Import API from URL & enter the URL of your API definition. In our case, the definition used is a swagger file. 

Select the New API  radio button.

Add the Web Api URL suffix.

Select the Protocols required & click Save.

Now your API should be ready to use. Click on the API to look at the details.


As you can see from the Settings page, most of the details are already filled for you.

The operations have also been imported.


We will now make this API available as a part of the "Starter" product. To do this, click "Products" as shown below.
Now click Add Products

Now check Starter and then click Save


Your API is now available to developers as a part of the "Starter" package.


Now that we have published this API, in the next post we will explore how rate-limiting is configured. We will look at the developer's perspective of the API (developer portal).




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

Comments

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 https://10.0.0.10/images.

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 :)

[TestInitialize]
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…