REST Architectural Principles and Statelessness

Representational State Transfer (REST) is an architectural style designed by Roy Fielding in 2000 for distributed hypermedia systems. REST governs how modern web services communicate over HTTP, enabling clients (web SPAs, mobile apps, IoT devices) and backend servers to interact reliably, securely, and scalably.

1. The Six Guiding Architectural Constraints of REST

To be considered a true RESTful system, an API architecture must satisfy six constraints:

2. The Core Principle: Statelessness

Statelessness mandates that no client session context is stored on the server between requests. Every single incoming request must contain all the information necessary for the server to understand, authenticate, and process it.

Stateful vs Stateless Comparison:

3. Uniform Interface & Resource-Oriented URIs

In REST, everything is a Resource. Resources are identified by stable, noun-based URIs (never verbs or actions):

4. Richardson Maturity Model

The Richardson Maturity Model breaks down the progression towards true REST:

• Level 0 (The Swamp of POX): Single HTTP endpoint with raw RPC calls (e.g. SOAP or basic XML-RPC).
• Level 1 (Resources): Distinct URIs for individual resources (/orders/123), but uses single HTTP methods.
• Level 2 (HTTP Verbs): Uses standard HTTP methods (GET, POST, PUT, DELETE) with meaningful HTTP status codes (200, 201, 404). Most production APIs operate here.
• Level 3 (HATEOAS): Hypermedia As The Engine Of Application State—responses include dynamic links guiding the client on valid subsequent actions.