Blog

Application Programming Interfaces (APIs) are vital components of software systems that are primarily used to retrieve and create business-critical information. Often, APIs have multiple consumer applications. In addition, those applications themselves often use multiple APIs. This many-to-many relationship is powerful but can create headaches when managing integrations between services. Additionally, you may face logistical challenges when dealing with any of the following: security, access control, rate limiting, exposure, and support for legacy versions of your APIs. It would take a lot of work to build a system around your APIs that account for all these challenges, and the good news is that it’s not necessary! Azure provides a service called API Management that makes managing APIs easy and intuitive. Let's look into some key features of API Management.

How Azure API Management Works

Azure API Management serves as a gateway between the consumers of your APIs and the APIs themselves. Adding this extra layer allows for a lot of neat things. One example would be providing a single point of access for multiple backend APIs. This is a great tool when you have many external APIs that you need to utilize but want to leverage a single point of access to group those dependencies. Another great feature is the ability to create rules for your APIs in the form of policies. Policies work like middleware in that they can modify inbound requests and the outbound responses from your backend APIs and even deny access to the underlying resources. Policies can be defined at four different layers in the API Management hierarchy: the API Management service, a Product (we will describe what this is later), an API, or a single operation within an API. This granularity of control allows for policies to account for very flexible and complex logic.

Rate Limiting and Quotas

Some extremely powerful policies that you can utilize in Azure API Management are the rate-limiting and quota policies. These policies allow you to set explicit limits on the number of requests made to the service. Just like any other policy, they can be defined at any of the four layers in the hierarchy, but they are only used on a request's way into the service. Rate limits are useful for managing the allowed number of requests during a smaller time period like seconds, minutes, and hours (which could protect from spamming your APIs and Denial of Service attacks). Quotas are used for managing the number of requests allowed over a more extended time period, such as per day, month, or year. Quotas can really come in handy when offering up APIs as services with subscription costs and tiers. For example, they would allow you to give a free tier subscriber 5000 requests/month, a standard tier subscriber 25,000 requests/month, and an unlimited tier subscriber an infinite number of requests.

Products and Subscriptions

Products are grouping entities that allow you to expose only the applicable APIs and policies to a given set of subscribers. For instance, if I had three separate APIs behind API Management, I could expose just one or two of them to a set of users by using a product. Consumers then become subscribers by subscribing to that product in the Developer Portal (we will describe what this is next) and receiving a Subscription Key. This key is what gives subscribers access to the APIs within a product in the API Management Service. Quota and Rate limiting policies can track the number of requests based on the subscriber key in order to keep track of which subscribers have exceeded their allotted requests.

 Developer Portal

The Developer Portal is the mechanism that allows API consumers to subscribe to products and view API definitions. The portal is a fully customizable and automatically generated website included out of the box for Azure API Management as long as you are using the Developer pricing tier or higher. The subscription process can be either automatic or requested. In the case of a free subscription, the process would likely be automatic since there is no payment requirement. However, in the case of a paid subscription, the consumer can request to subscribe, and then the API Management admin can approve this request. By default, the developer portal includes Username and Password login and registration capabilities, but there is also limited support for tying in other identity providers.

Revisions and Versions

The last thing we will talk about in Azure API Management is Versioning and Revisioning. These capabilities allow you to seamlessly make changes to your API Management definitions without disturbing consumers of the existing API definitions. Revisions allow you to make changes to a current API and test those changes before publishing those changes to your API Management service. This will enable you to test your changes and gain confidence before making them public. Once you "Make the revision current," you are publishing the API for all existing consumers to see your changes. Creating a new version essentially creates a new API based on your existing API that will contain additional changes. Consumers need to opt in to using this new version. This allows you to make breaking changes to your API while still maintaining an older version to support legacy consumers. You can allow users to opt-in by choosing a versioning scheme.

Conclusion

Azure API Management is an incredibly powerful tool, and it is just one of the many resources that Azure provides. Here at Omnitech, we are constantly researching new technologies and seeing how we can better serve our clients. Our Cloud and DevOps team has worked incredibly hard to explore the capabilities of Azure this past year. We can say with great confidence that Azure API Management is only the tip of the iceberg. We will continue to explore the flexible power of the cloud and increase our knowledge with Azure's many great resources.