Also known as: REST "representational state transfer"
REST (Representational State Transfer) is an architectural style for web APIs in which clients act on named resources, identified by URLs, using standard HTTP verbs over a stateless protocol.1
The core ideas
REST, described by Roy Fielding, organizes an API around a handful of constraints:1
- Resources and URLs. Everything is a resource — a message, a user, a device — each
identified by a URL like
/messages/42. The URL names the thing, not the action. - Standard verbs. The HTTP method says what to do:
GETreads,POSTcreates,PUT/PATCHupdates,DELETEremoves. Reusing the protocol’s verbs keeps the surface small and predictable. - Stateless. Each request carries everything the server needs; the server keeps no per-client session between requests, which makes REST services easy to scale.
- Representations. A resource is transferred in some representation, today most often JSON, that the client and server agree on.
REST also leans on HTTP status codes (200, 404, 500) as its error-handling contract, telling the client at the protocol level whether a request succeeded.
Why it’s common
REST became the default web-API style because it builds on HTTP that every client and server already speaks, requires no special tooling, and maps cleanly onto how people think about data (“the message at this address”). Its statelessness makes services simpler to cache, load-balance, and scale. Alternatives like GraphQL and gRPC exist and fit some problems better, but REST remains the lingua franca of web services.
In practice
A REST API is still an API, so its stability is a promise to callers:
breaking changes warrant a new major version under
semantic versioning, often expressed as a versioned path
like /v2/messages. Because REST endpoints are where many systems meet, they are a prime
target for integration tests and
end-to-end tests that exercise real requests against the
running service.