Effectively exposing fine-grained APIs and Microservices .
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.
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?
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
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**