API Basics: What Are APIs and Why They MatterLesson 1.5

REST Architecture Principles: The Six Constraints

REST constraints, statelessness, uniform interface, client-server, cacheable, layered system, code on demand, REST principles

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.

DiagramThe Six Constraints of REST

IMAGE PROMPT (replace this block with your generated image):

Flat hexagonal infographic on white background. Title: The 6 Constraints of REST Architecture. Six hexagons arranged in a honeycomb layout, each filled with a light tint of brand color #3A5EFF (#e8ecff), with a solid #3A5EFF border. Each hexagon contains: a small icon at top (line icon style), a bold number (1-6), a title, and a 5-word description. Hexagon 1: icon of two boxes, title Client-Server, description: Separate UI from data logic. Hexagon 2: icon of a request arrow, title Stateless, description: Each request is self-contained. Hexagon 3: icon of a lightning bolt, title Cacheable, description: Responses labeled for caching. Hexagon 4: icon of a gear, title Uniform Interface, description: Standard HTTP methods always. Hexagon 5: icon of stacked layers, title Layered System, description: Client unaware of intermediaries. Hexagon 6: icon of a code tag (optional badge), title Code on Demand, description: Optional executable code transfer. Center of honeycomb: the word REST in bold #3A5EFF. White background, clean sans-serif font.

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.

Ready to practice?

MCQs · Mini project