APIs provide the standardized contract that was missing from the SOAP environment. SOAP messaging and related protocols were used in the monolithic Service Bus Architecture or Enterprise Service Bus (ESB), in which device endpoints and applications communicated through the bus as opposed to a service contract. With API development, the contract between client and service no longer needs to wait for the service to be developed, further decoupling development teams. API-first design leads to better reuse and relevance for business-led “products.”
APIs have the important concept of a gateway. In the figure above, 2b illustrates the common and standard implementation of an API gateway, in which the key ‘policies’ are kept and centralised, controlled by the Control Plane, which can then configure, deploy and control the Data Planes. This approach is a decoupled architecture, similar to Kubernetes and almost the opposite of the SOAP-ESB architecture of ESBs.
The centralised deployment of an API gateway allows us to simplify the task of connecting to any API. An API gateway handles cross-cutting concerns such as authentication, logging, and monitoring, as well as orchestration to reduce round trips and provide the correct API for each client.
Some benefits in using API gateways, within complex, interdependent systems, in which back end services are shared across platforms and networks, and have many different types of end users would include:
Leaner microservices allow the centralization of common functions to reduce overhead. Rather than reinventing the wheel with every service, cross-cutting concerns such as authentication, logging, and monitoring can be handled at the gateway level. This also decreases overall system complexity, as these cross-cutting concerns can be implemented once in the gateway.
Decoupled clients and services allow for the orchestration of multiple microservices into one client API. Similarly, different clients can receive different APIs tailored to their needs, in a variation on the “back end for front end” pattern.
Accelerated API discovery speeds up the development of new clients and features.
Decreased number of required requests increases performance. Through orchestration, several API calls on the back end can be aggregated into one round trip between the client to the API gateway. This can improve the user experience.
Consistency through plugins enables best practice governance, security, observability, and handling of all other cross-cutting concerns.
ESBs were envisioned as the end-all, be-all solution to communication between all applications and services. As they grew into that role, additional features were added, allowing for business rules and logic to be incorporated into the system. As such, the ESB became too convenient. What began as a project to reduce system complexity evolved into a massively complex system which was quite expensive.
API gateways, on the other hand, play a more focused role. First, the API gateway is not responsible for (as much) transformation and protocol negotiation. As API standards have matured, the API gateway can be leaner than an ESB, focused specifically on cross-cutting concerns. Additionally, the API gateway is focused primarily on client-service communication, rather than on all service-to-service communication.
When to use an API gateway
API gateways are a good fit for businesses focused on moving faster and enabling innovation, which is achieved through distributed teams with the independence and ability to do their work.
ESBs fail this standard, as they are large, centralized monoliths that increase the coupling or interdependence between teams and decrease independence.
API gateways—with developer portals—also foster a design-first approach to APIs and promote a discovery-led consumption approach. By providing the right API for each client, API gateways can enable increased adoption, reuse, and iteration velocity. API gateways also facilitate the consumption and discovery of APIs across the organization and enable the use of no-code or low-code tools. Again, the focus is on enabling independent teams rather than coupling to the API gateway team.
