1. Overview

Nowadays, we know how APIs are the centerpiece of any successful digital product. Therefore proper API management is crucial.

In this quick tutorial, we’ll learn two objects that can help us in this direction, namely Reverse Proxy, API Gateway, and their differences.

2. Architecture

As we’ll see below, the capabilities they can offer change between the two, but the topology and the position within the infrastructure they occupy are the same. For this reason, we can depict them in the same way as follows:

API Gateway vs Reverse Proxy2

3. Reverse Proxy

One of the reasons it becomes useful to use a Reverse Proxy is to use it as a mediator between the client-side and one or more backend servers.
Let’s imagine having a microservices architecture and seeing them grow in number as the project evolves. At a certain moment, the complexity given by the heterogeneity of the API surface may arise the need to mask all this complexity. To do this, the Reverse Proxy can rewrite the URLs. The client doesn’t know who is beyond the Reverse Proxy. It’s the responsibility of the Reverse Proxy to forward the request to the backend that can fulfill it.

Typical uses of the reverse proxy include:

  • Load Balancing: it offers the ability to distribute incoming requests across multiple backend servers. Such load balancing prevents the overloading of individual systems and compensates for backend failures. If a backend becomes unreachable due to some errors, then its load balancing module redistributes incoming requests to the remaining backends
  • Protection from attacks: it offers the possibility of installing control systems such as antivirus or packet filters, which, by positioning themselves between the Internet and the private network, further protect the backends
  • Caching: for recurring requests, it can answer autonomously, in part, or completely. Content is often kept in the proxy cache. In this way, less data is retrieved from the backend, and clients get a response in less time
  • SSL Encryption: it can be configured to decrypt all incoming requests and encrypt all outgoing responses, freeing up valuable resources on the backend

At this point, if all of these capabilities aren’t enough, we likely need an API Gateway. Let’s delve into what the API Gateway further provides.

4. API Gateway

We can think of the Gateway API as a superset of a Reverse Proxy. Following, we will discuss the additional capabilities it has to offer.

Firstly, the API Gateway hides to the clients how the backends are partitioned in the architecture. Not only by forwarding requests but possibly performing orchestration/aggregation. This simplifies the client code and reduces the number of API requests/roundtrips. Furthermore, rather than invoking multiple backends, clients talk only with the API gateway.

Another feature related to the handling of requests/responses is Protocol Translation. In other words, the API Gateway can perform conversions from protocol to protocol (e.g., XML to JSON, gRPC to JSON) to facilitate the integration between client and server.

API Gateway is a great driver for addressing some common abilities such as security, reliability, scalability, observability, and traceability. Let’s see how.

To begin with security, it offers:

  • Authentication and Authorization: it centralizes at the edge who can request what
  • IP Whitelisting: it can grant the ability to use the APIs only to specific IP addresses

Moving on to those relating to performance:

  • Rate Limiting, Throttling, and Quota: we can set the limit based on how many requests/data servers can handle for a certain unit of time. Furthermore, looking more at the commercial aspect, it offers the possibility to control the traffic that API consumers are using based on the plan they’ve purchased
  • Retry Policy and Circuit Breaker: these are used to increase the resilience and reliability of backends by managing their temporary unavailability (e.g., re-perform the request on behalf of clients or protect servers from being flooded with requests)

To conclude with Observability and Traceability:

  • Logging, Tracing, Correlation: gather all the logs for each specific request, knowing which backends it has involved and the related metrics

5. Differences

To summarize, now that we have seen both individually, let’s summarize the main differences between Reverse Proxy and API Gateway:

Rendered by QuickLaTeX.com

6. Conclusions

In this article, having clarified the responsibilities of the API Gateway and the Reverse Proxy, we can choose appropriately based on the need for simplicity requested and the requirements and the problems we want to solve.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.