.png)
.png){kind=small}
.png){kind=small}
In my interactions with customer to discuss solutions involving the use of an API Management platform, the use case of integrating with partners consuming APIs exposed by the company is a common and generally well understood scenario. However, there are still some doubts when we talk about the use of the API Management platform to consume the APIs provided by partners.
The diagram below illustrates in a simple way a common scenario of using an API Management platform, exposing its backend services through an API Gateway and consumed by customer applications, including business partners.
In the above scenario, the exposure of backend services takes place in the context of a given company, which connects its legacy systems, databases, web services, ERP and microservices to its API Management platform, providing APIs for customer applications.
We can understand this context as the Customer Universe.
But in an increasingly digital, connected and open world, the adoption of APIs for integration between businesses and governments, of all sizes, becomes the new normal, leveraged by the impacts of COVID-19.
Therefore, in addition to the Customer Universe of APIs, there are also other contexts that need to be integrated: the Business Partners’ Universe of APIs. And an API Management platform can be a key piece to the successful integration of these different API contexts.
Imagine that your business partner exposes well-documented APIs for you to consume in your applications. So why would you include your API Gateway as another layer of architecture in this integration? In short, the answer is Safety & Control and Cost Optimization.
The API Gateway is the main component of an API Management platform. There are numerous benefits of adopting an API platform, such as security, governance, connections and transformations, among others. These benefits apply both to your internal APIs, which you are exposing to customer applications, and to your partners’ APIs that you need to consume.
These are some questions that help you understand why you should connect your partners' APIs into your API Gateway rather than a direct connection from your applications to those APIs.
You don't always need to use all the operations provided by an API, especially when there is a cost involved. By integrating your partners' APIs into your API Gateway, you can choose to expose only the APIs and operations required for your business processes, preventing the misuse of any operation.
Another important issue is the security involved in these APIs. Using the API Gateway you can create specific access plans for each customer application, limiting access only to the operations that application needs to have (principle of least privilege) and avoiding the sharing of access credentials, provided by your partner, for all customer applications that need to consume some API operation.
For APIs that handle sensitive or confidential data, you have the option to configure additional security policies in your API Gateway to encrypt some data or even obfuscate data in the audit logs.
And when your partner releases a new version of the API, you can easily perform an impact analysis from your API Gateway, identifying which customer applications consume a certain API and thus draw up an appropriate work plan to adapt to the new version and discontinue the use of the old version of the API.
In a more advanced security scenario, it is possible for your partners to manage the APIs provided by them directly in your API Gateway, through security features such as controlling organisations, teams and profiles, determining visibility rules for the resources and objects of your API Gateway, integrating with external user repositories through protocols like LDAP or SAML 2.0.
It is increasingly common for APIs provided by business partners to be monetised. APIs are treated as products of these companies, generating revenue by charging for their consumption, usually based on the number of calls to these APIs.
By including your partners' APIs in your API Gateway, you can implement policies to control calls to these APIs, limiting the number of calls in a period of time (rate limit) or avoiding peak calls (spike arrest), even if you have not yet reached the established limits.
There is also the possibility of configuring a cache policy when calling APIs, avoiding some triggers in the APIs of your partners for operations where the data does not change so dynamically.
In this article, I attempted to explore the scenario of integration with business partners through your API Gateway from a perspective where the partner provides the services to be consumed by your company, together with a more common scenario where a business partner consumes the APIs provided by your company.
There are several benefits to using an API Gateway, such as security, governance, connections and transformations, among others, but here I mainly highlighted security and control, in addition to cost optimisation.
How Developer Experience can transform your community and engagement with developers - https://www.sensedia.com/developer-experience
