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.
Each stage in order — click any step to read what it does.
RESTful URL structure with HTTP methods.
The trade-offs worth knowing before you build this.
/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.
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.
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.
Sign in to share your feedback and join the discussion.
