Skip to main content

Integration & IT Modernization

API Gateway Pattern

Effectively exposing fine-grained APIs and  Microservices .

Context

To support omnichannel applications with a different set of data requirements, backend applications are broken into fine-grained APIs or microservices.  Each front-end application has logic to call multiple APIs in order aggregate its data. In the case  of mobile and 3rd party apps, this client logic causes poor user experience since data is transferred over the internet. In addition, the client specific Security and SLM policies need to be implemented in each and every microservice which can be time-consuming  and redundant exercise.

By moving a clients’ aggregation logic from each application to API gateway, security and SLM policies are centralized, and user experience is improved through a transfer of aggregated data over a slow connection  in zipped format. Furthermore proxying the physical endpoint of a microservice in API gateway also helps in migrating microservices to a new platform or technology.

Problem

So how do you effectively expose a set of fine-grained APIs or microservices  while considering the different needs of each clients’ applications? For example, what if an enterprise has many front-end applications that require the unique set of data to be retrieved from  multiple APIs?

Solution

The API Gateway pattern is implemented as a single point of entry for all client applications to consume backend APIs and services.

Orchestration: API gateway can call multiple fine-grained  APIs\services and expose a  different set of APIs as a single API to each client, providing a different set of data based upon the client’s requirements.

Performance\Caching: An insignificant increase in Network latency due to additional hop can be overcome by adding a caching in the API gateway layer.  User experience can be greatly improved with an introduction of caching, resulting in fewer requests to backend systems. API gateway caching can also help in reducing the number of calls to pay-per-use cloud APIs/services model.

Security: Implementing client security (AuthN and AuthZ) at a single point of entry for APIs  to avoid redundancy of implementing client security for each and every APIs.

Other: Most of the vendor specific  API Gateways can provide transformation, enrichment, protocol conversion, transformation, load balancing, intelligent routing and Service level monitor capabilities.

This configuration is shown in Figure below

API Gateway Pattern

Common use cases of the pattern:

Need to provide aggregated API from a set of backend APIs and services.

Need to expose APIs to mobile and external partner applications.

Need to hide physical endpoint of API from the client for any future changes in implementation.

Need to provide client specific API from a single or multiple sets of APIs or microservices.

**This pattern should NOT be used for communication between the APIs or microservices**

 

Thoughts on “API Gateway Pattern”

  1. Praveen Sirupa

    What is the recommended the pattern for communication between 2 microservices? I wonder why not use the API Gateway pattern? If API Gateway is not used then, how does the provider microservice know that the call from consumer microservice is genuine? How is client security and authorizations are handled?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Rakesh Thakur

More from this Author

Follow Us