Constraints

1. Client-Server Architecture

Definition:

The client (consumer) and server (provider) must be separate entities, each responsible for its own concerns.

• The client handles the user interface and user interactions.
• The server manages data, business logic, and processing.

Benefits:

• Independent development of client and server
• Easier scaling and deployment

Example:

A mobile app (client) calls GET /books to fetch book data from the API (server). The app doesn’t need to know how the server stores data—just how to request and display it.

2. Statelessness

Definition:

Each client request must contain all necessary information for the server to understand and process it. The server should not store any session state between requests.

Benefits:

• Scalability (easier to distribute load across servers)
• Simplifies server logic

Example:

When calling GET /orders/1001, the client must include authentication info (like a token) with every request:

GET /orders/1001
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

The server doesn’t store session data — each request is processed independently.

3. Cacheability

Definition:

Responses must explicitly indicate whether they are cacheable (and for how long) using HTTP headers.

Benefits:

• Reduces server load
• Improves client performance

Example:

A response from GET /books might include:

Cache-Control: public, max-age=3600

This tells clients and proxies they can cache the response for 1 hour.

4. Uniform Interface

Definition:

REST APIs must have a standardized way of communicating between client and server. This is the core constraint that differentiates REST from other architectures.

Principles of Uniform Interface:

1. Resource Identification: Use URIs to identify resources (e.g., /books/10)

2. Standard HTTP Methods:

   • GET to retrieve
   • POST to create
   • PUT to update
   • DELETE to remove

3. Representation of Resources: Resources are sent in formats like JSON or XML.

4. Self-descriptive Messages: Requests and responses contain enough information (e.g., headers like Content-Type)

Example:

GET /books/10
Accept: application/json

Server Response:

{
  "id": 10,
  "title": "RESTful Web Services",
  "author": "Leonard Richardson"
}

5. Layered System

Definition:

A REST API must be designed in layers, where each layer has a specific responsibility. Clients cannot tell whether they’re connected directly to the server or through intermediaries (like load balancers or caches).

Benefits:

• Scalability via load balancing, caching, proxies
• Improved security and modularity

Example:

A client sends a request to api.example.com, which is routed through:

• a load balancer,
• then to an API gateway,
• then to a service running the actual logic.

The client is unaware of these layers.

6. Code on Demand (Optional)

Definition:

Servers can optionally send executable code to clients, allowing them to extend functionality.

Benefits:

• Flexibility
• Offloads processing to the client

Example:

The server responds with JavaScript code that runs on the client’s browser:

Content-Type: application/javascript

Client uses this script to render charts, validate forms, etc.

This is the only optional constraint. Most REST APIs do not use this in practice.

Summary

Constraint	Description	Benefit	Example
Client-Server	Separate UI (client) and data logic (server)	Scalability, modularity	Mobile app calls REST API
Stateless	No client session stored on server	Scalability, simplicity	JWT token sent with every request
Cacheable	Responses indicate cache policy	Performance, reduced load	Cache-Control header
Uniform Interface	Standardized interaction style	Simplicity, decoupling	GET /books, JSON representation
Layered System	Components are organized in layers	Scalability, security	Request goes through API gateway
Code on Demand (Optional)	Server sends code to client	Flexibility (rarely used)	JavaScript sent to browser