What makes an API RESTful — the 6 constraints
REST architectural style, statelessness, uniform interface, client-server separation, cacheability, layered system, code on demand
The Six REST Constraints
REST is not a protocol — it is a set of architectural constraints defined by Roy Fielding in 2000. An API is RESTful only when it satisfies all six constraints.
The Constraints That Matter Most
Stateless: Every request must contain all information the server needs. No session stored server-side between calls.
Uniform Interface: Resources are identified by URIs. You manipulate them through representations (JSON, XML). Messages are self-descriptive. Hypermedia drives application state (HATEOAS).
Client-Server: UI concerns are separated from data storage concerns. Frontend and backend evolve independently.
Cacheable: Responses must declare whether they can be cached. GET responses are typically cacheable; POST responses are not.
Cache-Control: max-age=3600, public
ETag: "abc123"Layered System: The client cannot tell whether it's connected directly to the server or through a proxy, load balancer, or CDN.
Code on Demand (optional): Servers can optionally send executable code (JavaScript) to clients. The only optional constraint.
Most APIs labeled REST violate HATEOAS — they are more accurately called HTTP APIs. That is fine in practice, but knowing the distinction helps you make informed design decisions.