REST
In plain English
Plain definition
REST is an architectural style for networked APIs using stateless requests, uniform resource identifiers and standard HTTP methods; correct use requires idempotency awareness, versioning discipline and explicit validation before any state-changing call.
Technical Definition
REST was defined as an architectural style rather than a protocol or product. A system is described as RESTful when it exhibits a set of constraints: a client-server separation, statelessness between requests, cacheable responses where appropriate, a uniform interface for interacting with resources, a layered system permitting intermediaries such as proxies or gateways, and, in its fuller form, hypermedia-driven interaction where responses contain links describing further valid actions. Most production APIs described as “REST APIs” implement only a practical subset of these constraints, commonly the uniform interface and statelessness, over HTTP with JSON payloads. This partial adoption is an observed industry pattern rather than a deviation the term itself requires reporting on for every implementation; teams should confirm which constraints their own API actually satisfies before relying on assumptions drawn from the term alone.
Operational Relevance
REST matters operationally because its constraints directly shape how a service can be scaled, cached, retried and debugged. Statelessness means any request must carry all context needed to process it, which simplifies horizontal scaling and load balancing but pushes session and authentication handling onto tokens or headers rather than server-held session state. The uniform interface makes automated tooling, API gateways, request logging and rate limiting more predictable, because behaviour can be reasoned about from the HTTP method and resource path rather than from bespoke per-endpoint logic.
Architecture Relationship
REST typically sits at the integration boundary between services, mobile or web clients, and backend systems. It is commonly paired with HTTP/HTTPS for transport, JSON or XML for payload encoding, and OpenAPI or similar specifications for contract definition. REST is often contrasted with RPC-style interfaces and with GraphQL: RPC exposes actions rather than resources, and GraphQL exposes a single flexible query endpoint rather than many resource-oriented ones. Within a larger architecture, REST endpoints are frequently fronted by an API gateway, protected by authentication and authorisation middleware, and observed through request logging and tracing at the layer boundary.
Example
A resource such as an order might be represented at a path like /orders/482. Retrieving its current state uses GET /orders/482, which should be safe and side-effect free. Updating the whole resource might use PUT /orders/482 with a complete representation, while a partial update uses PATCH /orders/482. Creating a new order might be POST /orders, and removing one DELETE /orders/482. Each of these operations, apart from GET, changes state on the server and should be validated against expected response codes and a defined rollback or compensating action before being relied on in an automated workflow.
Misunderstanding
A common misunderstanding is treating “REST” as synonymous with “any HTTP API that returns JSON”. Many APIs described informally as RESTful do not implement hypermedia controls, do not respect HTTP method semantics consistently, and sometimes retain server-side session state, which technically departs from the full architectural style even though the label is still used colloquially. This is worth being explicit about: the term describes constraints, not a specific transport or data format, and an API can use HTTP and JSON without satisfying REST’s defining properties, just as an API can technically satisfy those properties while using a different transport.
Related Terms
- HTTP — the transport protocol most REST implementations use to carry requests and responses.
- API gateway — infrastructure commonly placed in front of REST endpoints for routing, authentication and rate limiting.
- Idempotency — a property required of safe retry behaviour for methods such as PUT and DELETE.
- OpenAPI — a specification format commonly used to document REST resource contracts.
Further Reading
Practitioners validating or extending a REST-based workflow should confirm the current API version and any resource-specific constraints directly against the platform’s own documentation before applying assumptions from this general definition, since implementation details vary between services and change over time.