What are the six REST constraints?

Client-server, stateless, cacheable, uniform interface, layered system, and code on demand. The first five are required for an interface to be RESTful; code on demand is the only optional one. They come from Roy Fielding's 2000 doctoral dissertation that defined the REST architectural style.

What does stateless really mean?

Every request must carry all the information the server needs to process it — the server keeps no client session state between requests. This lets any server instance handle any request, so you can scale horizontally and load-balance freely. The cost is larger requests, since auth and context are re-sent each time rather than stored server-side.

What is the uniform interface constraint?

It is the central REST constraint, made of four sub-constraints: resources are identified by URIs, they are manipulated through representations, messages are self-descriptive, and hypermedia drives application state (HATEOAS). It decouples client and server at the cost of some efficiency, because data is exchanged in a standardized rather than application-specific form.

Is a JSON-over-HTTP API automatically RESTful?

Not necessarily. Many APIs called REST use HTTP verbs and JSON but skip the HATEOAS part of the uniform interface — they don't return hypermedia links that drive state transitions. Fielding considered such APIs HTTP/JSON APIs rather than fully RESTful. They are still perfectly useful; the label is just imprecise.

Which REST constraint is optional and why?

Code on demand — the server optionally sending executable code such as JavaScript for the client to run — is the single optional constraint. It is optional because it reduces visibility into what the client does, which conflicts with some deployments. The other five constraints are required for the architecture to count as REST.

REST Architectural Constraints

REST (Representational State Transfer) is not a protocol or a format — it is an architectural style defined by Roy Fielding in his 2000 dissertation. An interface earns the label “RESTful” only by satisfying a set of constraints. This reference lists all six with Fielding’s definition and the trade-off each imposes.

How it works

REST is defined by six constraints, applied on top of a network of components. Five are required; one (code on demand) is optional:

Client–Server — separate UI from data storage.
Stateless — each request is self-contained; no server-side session.
Cacheable — responses declare their cacheability.
Uniform Interface — URIs, representations, self-descriptive messages, HATEOAS.
Layered System — components only see the adjacent layer.
Code on Demand (optional) — server may send executable code to clients.

Each constraint buys a property — scalability, visibility, simplicity — usually at some cost in efficiency or latency.

Example

The stateless constraint is why a REST API authenticates every request with a token rather than a server-held session. Because no instance needs to remember the caller, a load balancer can route consecutive requests to different servers freely, and you can add or remove instances without sticky sessions. The trade-off is that the token and context travel on every request.

Notes

The uniform interface is what most distinguishes REST from RPC; its HATEOAS sub-constraint (hypermedia links driving state) is the part most APIs omit.
Layered system is what makes transparent caches, gateways and load balancers possible — clients can’t tell whether they’re talking to the origin.
Satisfying all required constraints yields the scalability and evolvability REST is prized for; violating statelessness or the uniform interface is what quietly turns a “REST” API into something else.

REST Architectural Constraints

Email me this result

How it works

Example

Notes