EMZETT.REST
In short: Representational State Transfer — an architectural style for web APIs, where resources are addressed via fixed URLs and standard HTTP methods (GET, POST, PUT, DELETE).
In more detail: Central principles: stateless (every request contains all necessary information, the server remembers nothing between requests), resource-oriented (URLs stand for things, not actions — /users/5 instead of /getUser?id=5), and uses HTTP status codes to signal error/success. It’s not a protocol, but a convention for how to use HTTP for APIs.
In Depth
GET /users/5 - fetch a user
POST /users - create a new user
PUT /users/5 - completely replace a user
PATCH /users/5 - change individual fields of a user
DELETE /users/5 - delete a user
The term “stateless” is central and often misunderstood: it doesn’t mean the application has no state (a user account is, of course, stored), but that the server does NOT remember the context of a previous request — every request has to bring all necessary information itself (e.g. an auth token). This makes REST APIs easier to scale (every server node can answer every request independently, with no shared session state) and easier to debug (every request is understandable on its own).
Strictly speaking, “REST” is an architectural style with several defined constraints (including cacheability and a uniform interface), not a fixed technology or protocol — in practice, the term is today often used more loosely for “a JSON-over-HTTP API with sensible URLs”, without strictly following all the original REST principles. Alternatives like GraphQL or gRPC solve the same basic task (client-server communication via an API) with different trade-offs, such as more flexible data querying with GraphQL.
Origin
The term REST was coined in 2000 by Roy Fielding in his doctoral thesis, one of the co-authors of the HTTP specification itself — REST essentially describes the architectural principles that already underlay the web (resources via URLs, stateless requests, caching via HTTP headers), formalised as a transferable pattern for API design. This explains why REST APIs connect so naturally with standard HTTP mechanisms (status codes, caching headers, content negotiation) — they’re basically a deliberate, consistent application of the web’s own architecture to programmatic interfaces, rather than to human-browsed websites.
HATEOAS — the often-ignored principle
One of the original REST constraints is most often ignored in practice: HATEOAS (Hypermedia as the Engine of Application State) requires an API response to contain not just data, but also links to possible next actions — a client should be able to “navigate” through an API, similar to how a human clicks through linked web pages, instead of having to know the complete URL structure documented in advance. The vast majority of interfaces called “REST APIs” today don’t implement HATEOAS and instead simply return plain data objects — pragmatically widespread, but strictly speaking not complete REST in Fielding’s original sense.
Using status codes correctly
A well-designed REST API meaningfully uses the full range of HTTP status codes, instead of just 200 (success) and 500 (server error): 201 Created after successfully creating a resource, 204 No Content after successful deletion with no return value, 400 Bad Request for faulty client input, 401 Unauthorized/403 Forbidden for missing/insufficient authorisation, 404 Not Found for a non-existent resource, 409 Conflict for conflicts (e.g. duplicate creation). This distinction lets client code react sensibly and programmatically to different error cases, instead of treating every error the same.