REST API Six Rules of REST

REST is not a protocol or a standard — it is an architectural style. Roy Fielding defined REST in his doctoral thesis in the year 2000. He laid out six rules (called constraints) that, when followed, produce APIs that are scalable, simple, and interoperable.

An API that follows all six rules is called a RESTful API. Understanding these rules helps you make better design decisions and avoid common mistakes.

Rule 1: Client-Server Separation

The client and the server are two separate things. The client handles the user interface. The server handles data and logic. They communicate only through the API.

┌──────────────────┐         API          ┌──────────────────┐
│                  │ ◀──────────────────▶ │                  │   
│  CLIENT          │                      │  SERVER          │
│  (UI, Mobile,    │                      │  (Data, Logic,   │
│   Browser)       │                      │   Database)      │
└──────────────────┘                      └──────────────────┘
      Knows nothing                              Knows nothing
      about the DB                               about the UI

This separation means you can change the mobile app without touching the server, and you can change the database without touching the app. They evolve independently.

Rule 2: Statelessness

The server stores zero information about the client between requests. Each request must contain everything the server needs to understand and process it.

❌ Stateful (bad):
  Request 1: "I am user Rahul"
  Request 2: "Give me my orders"   ← Server must remember Rahul

✅ Stateless (correct):
  Request 1: GET /orders  + Authorization: Bearer rahul-token
  Request 2: GET /orders  + Authorization: Bearer rahul-token
             (Each request carries identity independently)

Stateless servers are easier to scale. Any server in a cluster can handle any request because no session data is stored on a specific server.

Rule 3: Cacheability

Responses must tell the client whether the data can be stored (cached) and reused later. If a response is marked as cacheable, the client can save it and skip making the same request again.

First request:
Client ──▶ Server: "Give me product #42"
Server ──▶ Client: { data } + "Cache-Control: max-age=3600"

Next hour, same request:
Client uses the saved copy — no server trip needed ✅

Caching reduces server load, cuts response times, and saves bandwidth. It is one of the biggest performance wins in API design.

Rule 4: Uniform Interface

This is the most important rule. All REST APIs must follow a consistent, standard interface regardless of the server or technology behind them. This rule has four sub-parts:

  • Resource identification – every piece of data is a resource, identified by a URL
  • Resource manipulation through representations – the client gets a representation of a resource (like JSON), modifies it, and sends it back
  • Self-descriptive messages – each message carries enough information to describe how to process it (via Content-Type headers)
  • HATEOAS – responses include links that guide the client to related actions (covered in a later topic)
Uniform Interface in practice:
  GET    /books/7   → get book #7
  PUT    /books/7   → update book #7
  DELETE /books/7   → delete book #7

Same URL pattern works the same way everywhere.
No surprises.

Rule 5: Layered System

The client does not need to know how many systems sit between it and the server. There could be a load balancer, a cache server, a security gateway, and the actual database — all invisible to the client.

Client ──▶ [ Load Balancer ] ──▶ [ Cache ] ──▶ [ Auth Gateway ] ──▶ Server
             (Client only sees one address — everything else is hidden)

This lets you add layers for security, performance, or monitoring without changing the API interface at all.

Rule 6: Code on Demand (Optional)

This is the only optional rule. A server can send executable code (like JavaScript) to the client, which the client then runs. A common example is a server returning a JavaScript snippet that a browser executes.

Server response includes:
  { "widget": "..." }
  + <script> code to render the widget </script>

The client does not need to know how to render the widget in advance.

Most REST APIs do not use this rule. It is rarely needed in modern API design.

How the Six Rules Work Together

┌───────────────────────────────────────────────────────────────┐
│                      REST API Design                          │
│                                                               │
│  Rule 1: Client-Server ──── UI and data stay independent      │
│  Rule 2: Stateless ──────── Every request is self-contained   │
│  Rule 3: Cacheable ──────── Responses declare their freshness │
│  Rule 4: Uniform Interface ─ Predictable URLs and methods     │
│  Rule 5: Layered System ─── Hidden infrastructure             │
│  Rule 6: Code on Demand ─── (Optional) server sends code      │
└───────────────────────────────────────────────────────────────┘

Why These Rules Matter in Practice

APIs that break these rules cause real problems. A stateful API breaks when servers are scaled. An API with inconsistent URLs confuses every developer who uses it. An API that mixes UI logic with server logic becomes impossible to maintain as it grows.

Previous lessons
Back to courses
Next lessons

Leave a Comment