API gateway vs. reverse proxy

It is easier to think about them if you realize they aren't mutually exclusive. Think of an API gateway as a specific type reverse proxy implementation.

In regards to your questions, it is not uncommon to see both used in conjunction where the API gateway is treated as an application tier that sits behind a reverse proxy for load balancing and health checking. An example would be something like a WAF sandwich architecture in that your Web Application Firewall/API Gateway is sandwiched by reverse proxy tiers, one for the WAF itself and the other for the individual microservices it talks to.

Regarding the differences, they are very similar. It's just nomenclature. As you take a basic reverse proxy setup and start bolting on more pieces like authentication, rate limiting, dynamic config updates, and service discovery, people are more likely to call that an API gateway.

I believe, API Gateway is a reverse proxy that can be configured dynamically via API and potentially via UI, while traditional reverse proxy (like Nginx, HAProxy or Apache) is configured via config file and has to be restarted when configuration changes. Thus, API Gateway should be used when routing rules or other configuration often changes. To your questions:

It makes sense as long as every component in this sequence serves its purpose. Differences are not in feature list but in the way configuration changes applied.

Additionally, API Gateway is often provided in form of SAAS, like Apigee or Tyk for example.

Also, here's my tutorial on how to create a simple API Gateway with Node.js https://memz.co/api-gateway-microservices-docker-node-js/

Hope it helps.

API Gateways usually operate as a L7 construct.

API Gateways provide additional functionality as compared to a plain reverse proxy. If you consider some of the portals out there they can provide :

full API Lifecycle Management including documentation

a portal which can be used as the source of truth for various client applications and where you can provide client governance, rate limiting etc.

routing to different versions of the API including canary/beta versions

detecting usage patterns, register apps, retrieve client credentials etc.

However with the advent of service meshes like Istio, Consul a lot of the functionality of API Gateways will be subsumed by meshes.

API gateway acts as a reverse proxy to accept all application programming interface (API) calls, aggregate the various services required to fulfill them, and return the appropriate result.

An API gateway has a more robust set of features — especially around security and monitoring — than an API proxy. I would say API gateway pattern also called as Backend for frontend (BFF) is widely used in Microservices development. Checkout the article for the benefits and features of API Gateway pattern in Microservice world.

On the other hand API proxy is basically a lightweight API gateway. It includes some basic security and monitoring capabilities. So, if you already have an API and your needs are simple, an API proxy will work fine.

The below image will provide you the clear picture of the difference between API Gateway and Reverse proxy.

https://i.stack.imgur.com/bzSTZ.png

From HTTP: The Definitive Guide:

Strictly speaking, proxies connect two or more applications that speak the same protocol, while gateways hook up two or more parties that speak different protocols. A gateway acts as a "protocol converter," allowing a client to complete a transaction with a server, even when the client and server speak different protocols. In practice, the difference between proxies and gateways is blurry. Because browsers and servers implement different versions of HTTP, proxies often do some amount of protocol conversion. And commercial proxy servers implement gateway functionality to support SSL security protocols, SOCKS firewalls, FTP access, and web-based applications.