How an API Gateway Works

A load balancer picks among identical instances of one service. An API gateway decides which of several different services should handle a request.

Trace two requests arriving at the same address, https://registrar.university.edu. A member of the registrar’s staff opens /courses/add, a page in the registrar’s own application. CourseTracker sends GET /api/v1/courses/EN.601.226. Both requests reach the gateway first, at the one address every client already knows. The gateway looks at the path: /api/v1/... goes to the API service, everything else, including /courses/add, goes to the registrar’s application service. Each service handles the request as it always did, without knowing a gateway sits in front of it, and the gateway passes the response back to the client that sent the request.

Here, the load balancer’s instances are identical, so any healthy one will do; it does not need to know what a request is for, only which instance should handle it next, or which instance has the capacity. A gateway’s services do different things, so it has to know which one handles which request. That mapping, path to service, is not automatic. Someone configures it, the same way someone chose the /api prefix back when the API was designed.

This is also what keeps /api working now that the two services run on separate infrastructure. The path was chosen when the API and the registrar’s application shared one server. Splitting them did not require changing it, because the gateway handles the routing by path.

A gateway often does more than route. Every request already passes through it, so it is also a natural place to handle something that applies to every service the same way, instead of building the same check into each one. The API key check from the rate-limiting section is an example: a gateway can read the Authorization header, apply the appropriate rate limit based on whether a key is present, and reject requests over that limit before they ever reach a service. Logging every request in one place, instead of in each service separately, is another. Authentication beyond a single key, and tracing a request across several services, belong to observability, a later topic in this course.

A gateway is almost always software, commonly supplied by the hosting platform itself, the same as a load balancer. And like a load balancer, it is invisible to the client: REST’s layered system constraint said a client cannot tell whether it is talking to a server directly or to an intermediary standing in front of it. The gateway is one of those intermediaries.