Design APIs 10x Faster
Free. Runs everywhere.
On this edition of I’ll REST when I’m Alive, I will be exploring the differences and similarities between API Proxies and API Gateways. Expanding on my previous post, API Microgateways, I will also be discussing the advantages and disadvantages of both and the individual use cases.
A proxy, in its most basic form, is an intermediary acting on behalf of something else. Similar to the legal concept of a proxy, an API Proxy acts on behalf of the API instead of an individual. In more technical terms, an API Proxy decouples the frontend of the API from the backend services and filters all incoming and outgoing traffic. The decoupling of front-end and back-end services allows for changes to be made to backend services without disrupting the production API. The filtering of incoming and outgoing traffic allows for monitoring, basic forms of security, request routing, and protocol translation.
It is important to note that API Proxies require an existing API while some API Gateways can assist in building a new API.
API Gateways function in a similar way but have a much more robust set of features. Gateways perform the same functions as API Proxies, decoupling the frontend and backend of the API, monitoring, basic security, request routing, and protocol translation, but can also provide:
Request Shaping and Management
Static Response Handling
If you have different microservices with a set of shared common features, such as authentication, API Gateways can centralize that service so that it doesn’t have to validate each individual microservice.
Express Gateway (Open Source)
Zuul Gateway (Open Source)
Tyk Gateway (Open Source)
The advantage of an API Proxy is that it is essentially a lightweight, simple API Gateway. If you already have an existing API and just want to add some basic security and monitoring capabilities than an API Proxy would probably be the way to go. Many times, API Gateways are a part of larger API Management platforms since they play a part in the larger API lifecycle. This can introduce more complexity and can make them more difficult to manage and more expensive. Gateways must be maintained like any other bit of code and if you want to take advantage of the all the additional features then the level of complexity will increase. Also, take into consideration the price difference. There are many popular API Proxies that are open source while most API Gateways are proprietary.
Some API Gateways support importing and exporting APIs with the OpenAPI Specification.
API Proxy versus API Gateway
The use case for an API Proxy versus an API Gateway depends on what kinds of capabilities you require and where you are in the API Lifecycle. If you already have an existing API that doesn’t require the advanced capabilities that an API Gateway can offer than an API Proxy would be a recommended route. You can save valuable engineering bandwidth because proxies are much easier to maintain and you won’t suffer any negligible performance loss. If you need specific capabilities that a proxy doesn’t offer you could also develop an in-house layer to accommodate your use case. If you are earlier in the API lifecycle or need the extra features that an API Gateway can provide, then investing in one would pay dividends.
Photo - The Gardens of Lanhydrock House by Philip Halling
Bundling, dereferencing, and how to use them in Stoplight Studio and CLI workflows.
Mar 11, 2020