The role of API Gateways in Modern Enterprise

After my previous article on OAuth 2 scopes, several people contacted me to ask what exactly an API Manager is. In this article, I will aim to provide a clearer idea of why an organisation may choose to deploy an API Gateway solution and the associated benefits.

API Gateways

An API Gateway is an infrastructure component deployed by an enterprise at a network perimeter or a security boundary in order to act as a point of policy enforcement and control, and to facilitate service integration.

The role of an API Gateway is to act as a central point within an organisation through which clients can securely consume APIs.

That short sentence contains a number of important characteristics of an API Gateway so let’s further expand on them one at a time.

Service Virtualisation

Firstly, the API Gateway virtualises the services deployed behind it and exposes a fixed contract to the clients on the other side of it, enabling API implementations to be modified and even replaced without impact to the client.

If you think that this sounds a lot like the loose coupling concept behind an Enterprise Service Bus you would be right, except that ESBs are intended to decouple internal infrastructure components such as CRM systems, ERP systems and so on, whereas API Gateways are intended to decouple API consumers from the underlying API implementations.

Whilst ESBs decouple technologies which interact using a range of diverse protocols and messaging standards, API Gateways are (at least conceptually) only focused on services communicating via HTTP and HTTPS.

Additionally, in many cases one of the parties (consumer or producer) is located outside the enterprise perimeter.

API Transformation

In addition to virtualising an API implementation, an API Gateway may also transform an API to make it more suitable for use by the client which will consume it.

A typical example which we often implement for clients is in the context of service modernisation where a legacy service, perhaps implemented using SOAP/XML, must be made more accessible to modern REST/JSON clients.

Rather than rebuilding the service, implementing an equivalent REST/JSON solution or creating a wrapper service to perform the conversion, a simple transformation step, often referred to as a mediation policy, is activated on the API Gateway and makes use of capabilities already present within the Gateway solution.

REST API calls passing through the API Gateway are transformed into SOAP calls to the backend implementation and responses from the backend are transformed into equivalent REST responses before being forwarded to the client.

API Composition

Whilst most of the APIs exposed to clients via an API Gateway will have an equivalent backend API implementation, an API Gateway can also be used to expose an aggregated or composed API, created by combining the result of calls to several backend APIs.

In this way, small function oriented APIs or micro-services may be constructed by backend developers, and reused as building blocks to offer higher-level functionality from the viewpoint of a client.

Security, Enforcement, Monitoring and Audit

Finally, as all API calls are now passing through a central point, we can instruct the API Gateway to secure and validate requests before they are dispatched to backend services.

A security policy may be implemented on the Gateway component and will systematically be applied to API calls, removing the burden of implementing security requirements from backend API developers and protecting services against threats such as SQL Injection, XPath Injection and Denial of Service attacks. An API Gateway may also restrict the number of calls passed to a backend service based on Service Level Agreements between the organisation and the client.

An organisation may choose to offer its APIs only to known clients which must identify themselves before being granted service. This requirement can also be completely delegated to the API Gateway which may be configured to require a different proof of authorisation depending on the client or API being accessed. Furthermore as standards evolve and new identity solutions are developed, only the API Gateway configuration must be adapted to enable their use enterprise wide.

An API Gateway may also log some or all API calls either for service monitoring or auditing purposes, enabling organisations to known precisely who is calling which APIs and for what purposes, and in turn providing better insights for capacity management or governance requirements.

Summary

API Gateways are incredibly powerful components, capable of abstracting the “contract” of an API from its underlying implementation.

Through API Transformation and API Composition capabilities, API Gateways can modify the way that existing APIs are exposed, enabling organisations to tailor the form and capabilities of their APIs to their target client.

Finally, as a central point to access all APIs, they offer an opportunity to mutualise the investment required to secure APIs and can protect back-end services from bad actors who may seek to overload them or inject hostile content into service requests.