Code-Memo

REST Principles

What REST means (constraints)

  1. REST is an architectural style, not a framework: constraints include client-server, statelessness, cacheability, layered system, and (classically) a uniform interface.
  2. HATEOAS (hypermedia as the engine of application state) is part of the original model but is often skipped in practice.
  3. Practical APIs claim “RESTful” when they follow resources + HTTP semantics even if they are not hypermedia-driven.

Statelessness

  1. Each request should carry everything the server needs to authorize and process it (tokens, correlation IDs, context headers).
  2. The server should not rely on in-memory session affinity for correctness (scaling and failover get painful if it does).
  3. You can still use external stores (Redis, DB) for sessions or idempotency keys; the constraint is about not hiding required context only on the server node.

Resource-based design

  1. Model the world as nouns (resources) identified by URLs, not as unlimited RPC-style /doSomething endpoints.
  2. Use HTTP methods to express intent on a resource (GET read, DELETE remove, etc.).
  3. Prefer stable identifiers (/users/{id}) over operation names in the path.

Uniform interface concept

  1. Same patterns everywhere: predictable URLs, methods, status codes, and error shapes.
  2. Clients can rely on HTTP semantics instead of custom conventions per endpoint.
  3. Hypermedia links in responses are optional but improve discoverability when used.

Client-server separation

  1. Clients handle presentation and UX; servers handle data, rules, and persistence.
  2. This boundary lets you evolve backends and ship multiple clients against one API.
  3. Avoid leaking internal implementation details (table names, stack traces) across the boundary.