REST resources and methods

REST models domain nouns as resources identified by URLs. HTTP methods express intent; safety and idempotency guide retries and caching.

| Method | Safe | Idempotent | Typical use | |--------|------|------------|-------------| | GET | yes | yes | Read collection or item | | POST | no | no | Create, commands, non-idempotent actions | | PUT | no | yes | Replace whole resource at known URI | | PATCH | no | no* | Partial update (*often made idempotent) | | DELETE | no | yes | Remove resource |

					GET    /orders?status=open          # list
GET    /orders/42                   # read
POST   /orders                      # create (server assigns id)
PUT    /orders/42                   # full replace
PATCH  /orders/42                   # partial update
DELETE /orders/42                   # remove
POST   /orders/42/cancel            # sub-resource action when verb fits domain
				

Use plural nouns (`/users`, not `/user`). Nest for containment (`/orders/42/items`) but avoid deep trees that couple clients to storage shape. Prefer links in responses (HATEOAS lightly) or documented relation fields over guessing URLs.

On interviews: justify method choice for create vs upsert, when POST to a collection beats PUT to a client-chosen id, and how safety affects cache headers on GET.

Common pitfalls: using GET for state changes, POST for everything, verbs in URLs (`/getUser`), and exposing internal database keys without access control.

The trade-off is REST purity versus pragmatic RPC-style actions — document action endpoints consistently when domain verbs do not map cleanly to PUT/PATCH.

Checklist:

• Nouns in URLs; methods carry semantics.
• GET must not mutate state.
• POST for create; PUT for full replace at known URI.
• Sub-resource actions are explicit and documented.