REST Architecture Principles: The Six Constraints

REST Architecture Principles: The Six Constraints

REST is not just a set of HTTP conventions — it is a formal architectural style defined by six constraints. An API that satisfies all six constraints is considered truly RESTful. Understanding these constraints helps you make better design decisions and explains why REST APIs behave the way they do.

1. Client-Server Separation

The client and server are independent components connected by a uniform interface. The client handles the user interface and experience. The server handles data storage, business logic, and security. This separation means the two can evolve independently — you can rebuild the mobile app UI without touching the server, or migrate the database without the client knowing.

2. Statelessness

Every request from a client to a server must contain all the information needed to process that request. The server stores no session state between requests. Each request is treated as completely independent. This is why REST APIs use tokens (like JWTs) instead of server-side sessions — the authentication state travels with every request. Statelessness makes REST APIs horizontally scalable: any server in a cluster can handle any request because no server-specific state is required.

3. Cacheability

Responses must be labeled as cacheable or non-cacheable. When a response is cacheable, clients and intermediaries can reuse it for subsequent equivalent requests without hitting the server again. Use Cache-Control headers to define caching rules: Cache-Control: public, max-age=3600 tells clients the response can be cached for one hour.

4. Uniform Interface

The uniform interface is the central feature of REST. It standardizes how clients interact with servers through four sub-constraints: resource identification via URIs, resource manipulation through representations (JSON), self-descriptive messages, and hypermedia as the engine of application state (HATEOAS) — links in responses that guide clients to next possible actions.

5. Layered System

A REST client cannot tell whether it is connected directly to the origin server or to an intermediary like a load balancer, cache, or API gateway. Layering allows you to insert security, caching, and load balancing transparently.

6. Code on Demand (Optional)

Servers can optionally extend client functionality by transferring executable code — for example, a server sending JavaScript to be executed by a browser. This is the only optional constraint. Most REST APIs do not implement it, but it is part of the formal specification.