When you are building an API infrastructure there are a number of generic concerns you need to take care of, such as the authentication and validation of incoming requests. This can be a tall order to implement across a distributed set of applications or services.

This problem can be solved by an API gateway, which sits between API consumers and the applications that expose end-points. Its main role is to act as a “gatekeeper” for the wider API infrastructure. It provides a façade that de-couples public end-points from the code that actually executes requests.  This has a number of potential benefits:

• It can limit risk and exposure. If a gateway runs under limited privilege with no access there will be a limit to the damage an attacker can do once they compromise it.
• A gateway can authenticate incoming requests making it easier to implement a consistent authentication protocol across an entire API infrastructure.
• It can also validate incoming requests providing services such as rate limiting and quotas as well as protecting against certain forms of attack (e.g. buffer overload or denial of service)
• The separation of a public interface from the implementation detail makes it easier to manage a consistent and coherent API regardless of how the end-points are arranged internally.

The core role of the API gateway is to sanitize requests. It also helps to reduce the functional burden on individual API end-points who do not need to worry about authentication or validation of requests. So long as they trust the gateway they are free to assume that any incoming traffic is valid.

Keeping logic out of the gateway

Most commercial API gateway platforms see their remit much more widely than this core role of gatekeeper. An arms race tends to break out between vendors seeking to maximise revenue by broadening their appeal, giving rise to multi-purpose platforms that cover any potential customer use case.

If you don't strictly enforce the remit of API management it can give rise to creeping scope and an over-ambitious implementation. For example, API gateways usually provide services to shape or aggregate API responses. This is dangerous as it can lead to data transformation or rule processing logic to be implemented in a complex gateway rather than in applications managed by product teams.

In this sense API management platforms can start resemble enterprise service buses (ESB). These are platforms that are brought in principally to manage integration and workflow between separate systems. Given that they also provide tooling to transform and process data it becomes tempting to implement business logic in the workflow. The end result is usually a well of byzantine complexity that nobody understands and everybody is scared to change for fear of breaking something.

Generic middleware solutions tend to provide very complex programming environments that can implement processing logic, but rarely in a way that can be controlled or tested particularly easily. This logic is best kept in the hands of development teams who work closely with a domain rather than infrastructure or integration teams who manage middleware.

From API gateway to API management

It's not just transformation or workflow logic that can creep into API Gateways. Many high-end commercial gateway products such as CA API Management, Apigee and Mashery also offer a host of related functionality with the intention of serving as a fully-featured API management platform.

This functionality includes on-boarding and managing API users, publishing APIs and documentation, issuing access keys, reporting on API metrics and even billing. A portal is provided to surface all this along with content management facilities to brand the user experience.  This represents an escalation of the gateway's role from gatekeeper to an all-singing, all-dancing publishing and promotion platform.

Some of the more established data integration platforms such as Dell Boomi, Mulesoft and WS02 are creeping into this space by offering API publishing facilities. This threatens to subsume the gateway into a single, monolithic data platform that is responsible for transforming and publishing all your internal data. The benefits of using a gateway can easily get lost in the maintenance burden of a complex and over-ambitious middleware.

Defining clear responsibilities

There is a strong case for an API gateway – I wouldn't try to build an API infrastructure without one. It solves a number of generic problems such as authentication and rate limiting that might otherwise have to be solved by each individual application.

The trick is to ensure that a gateway's responsibilities do not creep beyond the tightly-defined role of a “gatekeeper”. Third party gateway platforms are valuable in that they provide robust solutions for these generic problems, but they should be confined to a carefully defined remit rather than being allowing to take over your entire API infrastructure.

Filed under API design, Architecture, Design patterns, Integration and Strategy.