REST Principles

REST Is Constraints, Not URL Style

REST (Representational State Transfer) is six architectural constraints. APIs commonly called “RESTful” mostly implement a subset — knowing which constraints do which work separates design from convention-following.

 1. CLIENT-SERVER        separation of UI from data store
 2. STATELESS            each request carries everything needed
 3. CACHEABLE            responses declare their cacheability
 4. UNIFORM INTERFACE    resources, standard verbs, self-descriptive messages
 5. LAYERED SYSTEM       intermediaries (CDNs, proxies) invisible to clients
 6. CODE-ON-DEMAND       (optional) server extends client logic
 
 constraints 2–5 are where system-level value concentrates

Statelessness: The Scaling Constraint

No session state lives on servers; each request is self-contained:

 STATEFUL                          STATELESS (REST)
 server remembers login            every request carries its proof
 sticky sessions required          any server serves any request
 node loss = logged-out users      node loss = nothing special
 scaling = complex replication     scaling = add machines behind LB

 mechanism: tokens (JWT/session keys) travel with each request;
 auth happens per-request from the token + shared verification

Statelessness is the reason REST-era systems scale horizontally for free. It is also why auth design matters at the API layer, not just the security layer.

Uniform Interface

Four sub-rules, two of which dominate practice:

 RESOURCE IDENTIFICATION   URLs name things: /trips/123
 STANDARD VERBS            GET/POST/PUT/PATCH/DELETE carry semantics
 SELF-DESCRITIVE           Content-Type, status codes mean what they say
 HATEOAS                   responses link to next legal actions (rarely adopted)
 
 practical core: nouns in paths, verb semantics in methods,
 meaning in status codes — not in response bodies alone

Cacheability and Layering

 Client ──► [CDN] ──► [LB] ──► [Service Mesh sidecar] ──► Server
            all of these may serve/cache/transform because
            responses DECLARE: Cache-Control, ETag, Vary
            
 explicit cache headers are what let intermediaries help safely;
 absent them, every intermediary must pass through → origin load

This constraint quietly powers CDNs: correctness by declaration rather than out-of-band coordination.

Where Strict REST Bends in Practice

Constraint	Common deviation	Why
Uniform verbs	POST for everything complex	Expressiveness beats purity
Full REST resources	RPC-ish action endpoints	Some domains aren’t CRUD
HATEOAS	skipped almost universally	Tooling cost exceeds benefit

Pragmatic teams build HTTP APIs following REST conventions — and that is fine, provided the deviations are consistent.

Interview Framing

“Why REST?” answered with mechanics scores: stateless requests enable horizontal scaling; declarative caching enables CDN layering; uniform interface reduces per-endpoint learning. Candidates citing “it’s standard” without mechanism invite the follow-up “when would you NOT use it?” — have gRPC/streaming answers ready.