HATEOAS, idempotency, uniform interface, versioning strategies.

REST Principles — Resource Design, HTTP Methods, and Status Codes

REST (Representational State Transfer) is an architectural style for distributed hypermedia systems. Six constraints: uniform interface, stateless, cacheable, client-server, layered system, code-on-demand. In practice: resources are nouns (/orders/42, not /getOrder), HTTP methods convey semantics (GET=read, POST=create, PUT=replace, PATCH=update, DELETE=remove), status codes are meaningful (201 Created, 404 Not Found, 409 Conflict). Idempotent methods (GET, PUT, DELETE) produce the same result regardless of how many times called.

Interactive Pipeline Flow

UnderstandImplementOptimise

📦 Resource — noun, not verb

Resource naming: /users (collection), /users/42 (resource), /users/42/orders (sub-resource). Nouns not verbs. Plural for collections. Lowercase with hyphens.

Architecture Diagrams

Choosing the right HTTP status code for each scenario.

Loading diagram...

Key Design Decisions

📦Resources are nouns, not verbs

/processPayment and /getUserOrders are RPC-style, not REST. /payments (POST to create), /users/42/orders (GET to list). Noun-based URLs are more intuitive and composable.

🔢Return 409 for business conflicts, 422 for validation failures

409 Conflict: the request is valid but conflicts with existing state (duplicate email). 422 Unprocessable Entity: the request is syntactically valid but semantically wrong (age: -5). Both are client errors with different meanings.

🔄Idempotency keys prevent duplicate operations

Payment creation via POST is not idempotent without an idempotency key. Add Idempotency-Key header support: same key returns same result. Prevents double-charges on network retries.

Discussion