Skip to main content

Azure API Management - Add rate limiting & consuming the api (Part 4)


Introduction

This is part 4 of a series of blog posts where I will be talking about how rate-limiting is configured. We will look at the developer's perspective of the API (developer portal).

In the last post we published the "yo-blog" API via the publisher portal. The URL of the publisher & developer portal is https://mgtdemo.portal.azure-api.net/. In this post we will need to log into this portal as both:
  • An API Publisher
  • An API consuming developer (using the API)



Rate Limiting & Products

Rate limiting is tied to the "Products".

"Products" essentially refer to your API offerings. In this example we will create an API offering with the following settings.



To accomplish this, log into the publisher portal & click "Products" & click
ADD Product". Then follow the screenshots below.

Click Products & then click ADD PRODUCT

Then add the details for the new product. Then click Save.


Then click on the newly created product


Next navigate to visibility & check the appropriate visibility then save

Also, don't forget to "Publish" your APIs.


Rate limiting a product

You now need to click on policies & then click Add Policy



As you can see, a policy does not exist for the "Api Testing Plan". Click it to create one.
You then need to click the option to "Limit call rate per subscription". This should automatically set the correct XML config like so: (check next image)




After modifying the values, your XML looks like so ..

Your rate limit is 1/ per 60 seconds & quota is 10 calls per 10 days

Assign the Product to an API

You need to navigate to your API, then navigate to the Product tab & delete the "Starter" Product & add the "API Testing Plan" product.








Consuming the API

Now that the APIs have been published, lets look at what a consuming developer experiences. 

Our APIs are now published & available at the API Portal https://mgtdemo.portal.azure-api.net. When they navigate to the URL, they will see a default home page. If your API's product allows for "Guest" visibility & DOES NOT require subscription,  your API definition will also be visible. This means by default, any API linked to a "Starter" product offering will be visible without logging in.

(More to come ...)





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…