Back in June, I wrote a blog post on API Management and how you can use API Management policies to enforce access restriction policies. I was going to write a follow up post on how to use API Management policies in additional scenarios, but it’s one of those scenarios where great minds think alike!
We recently introduced you to API Management, how it maps to architectural principals and why you may consider using it as a producer or consumer of APIs. In this post, we’ll be continuing on the story - focusing mostly on the API Management policies functionality.
We now live in a world where multiple systems connect or integrate with each other. This is not new, and has been a technology trend for some time. But - in a world of distributed compute (on the increase, thanks to cloud), and the rise of microservices, we find that we have more and more services that we need to integrate with each other. Integration is typically handled through a couple of routes, including Enterprise Messaging (such as message brokers), as well as APIs (Application Programming Interface). There are many areas that we should consider when building our APIs, and that’s what we’ll give some thought to in this blog post.