How does REST, as an architectural style layered on HTTP, encode client-server request-response mechanics plus its statelessness constraint, and what does that constraint forbid a server from doing between requests?

## Two layers, routinely conflated HTTP and REST are two different things that are often conflated: HTTP is the transport protocol, and REST (Representational State Transfer) is an architectural style — a set of constraints — that HTTP happens to satisfy well when used a certain way, which is why "REST API" almost always means "an HTTP API designed according to REST's constraints." Understanding how they instantiate the client-server style means looking at both layers. ## The HTTP layer At the HTTP layer, the client-server shape is explicit in the protocol design: - A client (a browser, a mobile app, curl, another backend service acting as a client) opens a TCP connection and sends a request line — a method (`GET`, `POST`, `PUT`, `PATCH`, `DELETE`), a path identifying a resource, headers, and optionally a body. - The server, listening on a port, receives that request, does whatever work it implies, and sends back a status line plus headers and a body. - The server never initiates an HTTP request to a client on its own; the client always goes first, which is the base client-server asymmetry. ## What REST layers on top REST adds architectural constraints on top of raw HTTP's request-response mechanics, and the one most relevant here is **statelessness**: REST requires that each request from client to server contain all the information the server needs to understand and process it, with no reliance on server-held context from a previous request. Concretely, a RESTful API doesn't say "remember, I logged in three requests ago, so trust this one" — it requires the client to send an auth token on every single call, and the server validates that token fresh every time rather than consulting an in-memory "is this connection authenticated" flag. REST also mandates a **uniform interface**: resources are manipulated through a small, fixed set of verbs with agreed semantics, and responses are self-descriptive via content-type headers. | Method | Its agreed semantics | |---|---| | `GET` | is safe/idempotent and doesn't change state | | `PUT` | replaces a resource idempotently | | `POST` | creates or triggers a non-idempotent action | | `DELETE` | removes a resource | ## Why the constraint is hard rather than optional The reason REST bakes statelessness in as a hard constraint, rather than leaving it optional, is precisely the scalability argument central to this leaf: an HTTP server that holds no per-client session state can be freely replicated behind a load balancer, because literally any instance can service literally any request — there's no need for sticky routing, and a crashed instance loses nothing session-related. It also makes intermediate components — caches, proxies, CDNs — able to reason about and cache a response purely from the request that produced it, without needing to track a session. ## The trade-off The trade-off, as with stateless servers generally, is that every request now carries more: authentication has to be re-verified on every call, and any multi-step process that would naturally be "stateful" in a raw protocol has to be re-modeled as a series of self-contained requests against a persisted resource — e.g., a shopping cart is a resource with an ID that the client fetches and updates by ID on each call, rather than an in-memory server-side object tied to a live connection. ## Failure modes Failure modes here are distinctive to REST-over-HTTP: - **Incorrect use of HTTP methods** (a `GET` that has side effects, breaking caching and idempotency assumptions — browsers and proxies may retry or prefetch GETs assuming they're safe) causes subtle bugs. - **Treating an inherently stateful workflow as if REST's statelessness didn't apply** (storing an in-memory "current step" on the server keyed by IP or an implicit session) breaks the moment the request lands on a different server instance behind a load balancer, producing intermittent "my progress vanished" bugs hard to reproduce on a single-instance dev setup. ## Where you have already seen it A concrete, well-known real-world instance: the GitHub REST API requires a token in the `Authorization` header on every call — there is no notion of "you already authenticated a minute ago" — which is precisely what lets GitHub route any given API call to any of its many backend instances without needing session affinity.