What is Azure APIM?

Hello and welcome back, today I'll be talking about the basics of Azure APIM, how it works and why managing your APIs through it is a good idea.

Now to answer the burning question. What is it?
To put it simply it is a PAAS (Platform as a Service) offering, available in Azure and is used to further add governance to software exposed in your network. This is done by enforcing certain policies, creating products and allowing testers to test APIs exposed through the developer portal in APIM simplifying testing procedures to a degree.


Why it is Important:
In short security. In todays modern tech landscape, cyber attacks are everywhere and by exposing API's through APIM you can ensure that certain security protocols are strictly followed in your organization. This is done by attaching certain policies to an API or Product. I'll go into them more in depth later on but, these are pieces of functionality that can help enable your API's. From removing headers from responses to, enforcing JWT validation on inbound requests. It allows for greater compartmentalization and abstraction of software consumed in your organization. It's not only used for software developed inside of your organization but, also can be used to secure and abstract third party software as well.

Structure:
In APIM there are several key pieces to make note of. These are essential elements of the service that you need to understand. Those are:

Policies:
These are pieces of functionality that can enable your API's or Products. They essentially allow you to run some simple functions when an API or Product is in a particular state such as when forwarding a response from the backend service. They can be implemented at several scopes in your APIM environment from: API, Product or Global. Its worth noting that where you place a policy matters. As in if you define a cors policy at the Global scope and another at the API scope, the policy at the Global scope gets implemented and not the one at the API scope. The policy priority is as follows: Global > Product > API.

Named Values:
Think of these more as variables. They are very limited in what types they can be, but the benefit of using them is that they allow you to configure the settings of a Policy without having to search for or edit the Policy itself.

API:
These are objects that represent the API's/ Web Apps/ Chunks of code (for lack of a better term) that need to be exposed in your organizations network either privately or publicly. Think of them like an abstraction from your web apps or other REST/ SOAP services, with the added benefit of being able to make all API's exposed in APIM more concise in there appearance and structure and also hiding internal backend resources. APIs are split into three sections: inbound, outbound and backend. The inbound section is for policies that manage inbound requests such adding JWT validation to the Authorization header of a request to mapping request bodies to a particular format. The outbound section is for policies that deal with responses from the backend service, this can include removing certain headers or masking sensitive content. Finally the backend section is for policies that manage the backend service such as editing the backend service defined in the API.

Products:
These define a subset of APIs accessible through a specific subscription. This can be useful in defining which API's are accessible in which Product. Products can have policies like API's and are also split into the sections: inbound and outbound. However of course Products manage a different context to APIs so the policies that can be added to it differ from those that can be added to an API. For example, you can add an IP whitelisting policy to the inbound section of a product but not the inbound section of an API.

Subscriptions:
If you'd like you can think of each subscription as a set of scoped access keys for your APIs. It sounds simple and it is... however they are very important. Subscriptions can help analyze issues and errors from APIs for a specific consumer as well as more importantly granting access to APIs. In APIM a valid subscription key is required to access any API and is added to HTTP requests via the subscription key header. This header is defined in your API definition in APIM. Subscription keys are scoped, as in they can be used at different access levels those are: All APIs, API, Product. The scopes are self explanatory. All APIs grants subscription keys access to all APIs in APIM. API grants access to a single API in APIM and Product grants access to all APIs within a particular Product.

The Developer Portal:
This is a website that is automatically generated with the APIM deployment. However, it is fully customizable. To test APIs through it you need to create a an account through the website. It is as simple as that really, you will still need subscription keys to test API's in it though.


Other Things of Note:
APIM is an acronym for API Management. I'm not sure if it worth mentioning it but.... you never know.


Thanks for reading my short post on the basics of Microsoft Azure API Management Service. Feel free to connect with me on linkedin if you'd like. I hope that this helps.