An API gateway is an interface between clients and backend microservices. When a gateway is used, it becomes the single point of contact for clients; it receives their API calls and routes each one to the appropriate backend.
API gateways create abstraction of the backend. This provides a number of benefits for organizations that use them.
It facilitates microservice architectures. When an API gateway is used, clients do not know (nor should they know) the structure of the backend. Modern architectures discourage the use of large monolithic services; rather, numerous small microservices are preferred. This approach provides some compelling advantages, but it does introduce significant complexity. An API gateway mitigates this for the client.
For example, an e-commerce store might have a mobile app that displays product details, pricing, reviews, and other information on each product page—but each category of data is provided by a different backend microservice. In this situation, an API gateway provides a single point of contact for the client application; the gateway communicates with all the microservices, aggregates the results, and serves them back to the client. The application client does not know, or care, how all the information was collected and provided.
This provides developers with much more freedom to restructure and refactor the backend architecture as business needs evolve.
It insulates the microservices from direct client access. When the backend is not directly accessible from the outside, this can create additional options for developers. For example, there might be reasons to use a web-unfriendly protocol for internal communication within the backend.
It simplifies the client. Clients do not need to know which microservice instances to access, or where they are located, or how to communicate with them. All this functionality is moved to the gateway.
It increases performance. When a client calls a backend, each call introduces network latency. If the client is communicating directly with multiple microservices, then multiple calls are required. Conversely, when a client calls an API gateway, it is possible to consolidate everything into one request and one response.
API Gateways and Web Security
Some API gateway vendors also include web security functionality in their products. At first glance, this seems to make sense. After all, an API gateway is the Internet-facing component of the system; it seems logical that it should be the component that protects the backend from API attacks.
However, this logic does not withstand scrutiny. An API gateway is not the optimal component for backend protection. There are several reasons for this.
Redundant functionality. Backend microservices must be protected from the same threats as web applications: vulnerability scans, hacking and breach attempts, DDoS attacks, and so on. Presumably, an organization will already have a WAF (such as AWS WAF) in place to protect its web applications. If an API gateway must perform the same role for its endpoint(s), then there are two separate system components performing essentially the same role.
Difficult maintenance. The Internet threat environment is both complex and continually changing. It is often difficult for admins to keep one WAF up-to-date, never mind maintaining a second WAF-equivalent as well.
Inadequate security. There is a wide variety of possible web attacks, some of which can be quite sophisticated. An effective web security solution must protect against all of them. Even for dedicated WAF vendors (such as AWS WAF), this can be challenging, especially when the system includes one or more API endpoints. (For more information, see API Security versus Traditional Web Security.) Therefore, it is unrealistic to expect effective performance from API gateway products for which web security functionality is merely an add-on.
Protecting APIs
API gateways offer a number of advantages, but robust web and API security is not among them.
The best approach for protecting an API is to deploy a cloud web security solution in front of it as a reverse proxy. A comprehensive security platform can block hostile requests and scrub traffic of all kinds—not only the incoming traffic for web applications, but also for API endpoint(s).
This preserves the advantages of an API gateway (the single point of contact for clients, backend abstraction, flexibility of architecture, and so on), while also hardening the gateway and backend network against Internet threats, and without adding to the administrative burden of IT staff.
