Azure API Management (Part 2 – Overview)
In our previous blog Azure API Management (Part 1 – Introduction), we saw the basic features of API and the need to implement Azure API Management.
This article gives an overview of Azure API Management (APIM) components and the common user scenarios.
Now, let us discuss the components of API.
There are three components of APIM namely, API Gateway (API Proxy), Azure Portal and Developer Portal.
- API Gateway (or Proxy) is where the API calls are accepted and is exposed to the callers. When gateway receives a request, it re-maps the URL and forwards it to back-end API and performs caching. This back-end API can be hosted on Azure or on-premises.
- In Azure Portal, you as an owner (or admin) of API can create and edit APIs. The behaviour of API and access permissions to it can be configured here. Also, you can view analytics for usage and performance of your APIs and customize the look and feel of developer portal.
- In Developer Portal, you can read API documentation. There is an interactive console which allows the developer to test the behavior of API directly in the browser. It asks for the values for URL parameter and automatically adds the developers key in the subscription-key parameter.
Next question – who can access APIM?
Many types of people can access APIM and they are categorized according to Groups. API management has the immutable system groups divided into Administrators, Developers and Guests. Administrators create APIs, operations and products that are managed by the developers. Developers have access to Developer Portal and can build the operations that can call the operations of an API. Guests can be prospective customers who want to access developer portal. They are granted read-only access to view APIs even though they are restricted to call them. Finally, there is also a Custom group which admins can leverage external groups in associated AAD tenants.
Finally, what are the common scenarios where Azure APIM can be used?
To use API Management, administrators create APIs. Each API consist of one or more operations, and each API can be added to one or more products. To use an API, developers subscribe to a product that contains an API, and then they can call the APIs operation. This is the usual flow of APIM. Some of the common scenarios include securing mobile infrastructure by getting access with API Keys, preventing DOS attack; enabling ISV partner ecosystem by offering a fast partner onboarding through the developer portal; running an internal API program by offering a centralized location for the organization to communicate about the availability and latest changes to APIs, getting access based on organizational accounts.
To conclude, we have seen the advantages of APIM over API by looking at the features the former provides. We also learnt about the components and the users of APIM along with the common usage scenarios.