The Six REST Constraints
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
REST combines six constraints: client-server, stateless, cacheable, uniform interface, layered system, and code-on-demand. Code-on-demand is the only optional constraint; the other five form the base REST style. Using HTTP, returning JSON, or exposing CRUD endpoints does not by itself show that these constraints are present.
Client-server separates user-interface concerns from data and service concerns so each side can evolve independently. Statelessness requires every request to carry the context needed to understand it. The server may still store resource state such as orders and users; it must not depend on hidden client-session context from an earlier request. This lets the next request reach any suitable server instance.
Cacheable means a response defines whether and how it may be reused. Layered system means a component sees only its immediate neighbour, so caches, proxies, gateways, and load balancers can sit between client and origin. A GET /orders/42 may be answered by an allowed cache or forwarded through a gateway without changing the client contract. Poor freshness rules risk stale data, and extra layers add latency and failure points.
Uniform interface gives every component the same interaction model. Its four parts are resource identification, manipulation through representations, self-descriptive messages, and hypermedia as the engine of application state. For example, /orders/42 identifies a resource, while the method, status, headers, media type, body, and links explain the exchange and possible next actions. Method names alone do not satisfy this constraint.
Code-on-demand allows the server to extend a client by transferring executable code, with browser JavaScript as the familiar example. It is optional because it can reduce visibility into client behaviour, and most JSON APIs do not need it. Together the constraints support independent change, visibility, caching, intermediaries, and scale, but they do not automatically provide security, correctness, or good performance; those still depend on the implementation.
The Six REST Constraints
Direct Answer
The six constraints of REST are client-server separation, stateless communication, cacheability, a uniform interface, a layered system, and optional code-on-demand. They work together to improve visibility, independent evolution, scalability, and intermediary support. Code-on-demand is the only optional constraint; using HTTP and JSON alone does not prove an API follows REST.
Deep Dive & Architecture
Fielding derives REST as a constrained architectural style. Each constraint creates benefits and costs. Client-server separation improves portability and independent evolution. Stateless interaction improves visibility and makes requests easier to route, but repeats contextual information and moves application-state responsibility to the client.
Caching adds efficiency by reusing a prior response when its rules allow. It can reduce consistency if freshness is chosen poorly, so responses label their reuse semantics. A layered system allows intermediaries to add security, translation, load distribution, or caching without changing the client interface, while adding latency and making end-to-end behavior less obvious.
Uniform interface trades some application-specific efficiency for a shared way of interacting. A representation describes current resource state; metadata explains how to interpret it; controls identify possible next transitions. This is why a collection of RPC-style JSON endpoints does not become REST merely because it uses HTTP verbs.
Code-on-demand is optional because downloading executable behavior can improve client extensibility but reduces visibility. Browser JavaScript is the familiar example. An API can omit it and still conform to the other constraints. REST is therefore assessed by architectural behavior, not by a checklist of route naming conventions alone.
Code Example
GET /orders/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer <credential>
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, max-age=30
ETag: "order-42-v7"
{"id":42,"status":"draft","links":[{"rel":"confirm","href":"/orders/42/confirmation"}]}
The request carries its credential, the representation is self-descriptive through metadata, caching is explicit, and the response includes a control for an available transition. A gateway could carry the exchange without changing that contract.
Check your understanding
Answer these without looking back at the article.
- Which REST constraint is optional?
- What are the four parts of the uniform-interface constraint?
- Why does using JSON over HTTP not automatically make an API RESTful?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.