Introduction
I don’t have that much experience with APIM (API Management) and I haven’t seen all the features of APIM but one of the functionalities 📐 that really hit me are the policies. What an amazing feature, and not a new one either.
Note that this post only covers a part of APIM policies.
What is it?
APIM Policies is basically an interceptor 🥷 with the possibility of transforming the information before it reaches the backend and also the response back to the caller. Ok… 🤨? Let me give you a real-world example.
What the APIM does in illustration above is to process the incoming information into whatever you’ve configured it to do. So smack talk is translated into positive response.
Note that the policy is one of many features in APIM.
Our Challenge
The challenge we faced is that the caller, to our service, for some reason does not follow the best practices of HTTP/OAuth 2.0 requests. With that in mind, using policies in APIM helped us to overcome the challenge by transforming ♻️ the request data to our API. Since the caller at the time didn’t want to change anything from their side, this was the best option and most time saving solution instead of demanding them to do the change on their side.
To give you one of few concrete examples of what we did. Many of our endpoints are configured as POST method rather than GET due to the nature of the process . Using policies, we transformed GET to POST within APIM. That way we did not need to change the http method on our endpoint. Also, we converted their content-type from json to x-www-form-urlencoded on one of the endpoints.
You can do a lot more with policies, such as removing parts of the url, include additional data to request body, removing sensitive data from payload, rate limiting, etc etc, but I won’t go into details about that. There are other great posts about it 🙂
Last words
You don’t always need to force a change on the caller. Sometimes you just have to take it, twist it, bake it and you’ll get exactly what you want 😁
Relevant Links
Van Carl Nguyen 