Skip to content
REST API Design — From Zero to Hero

Methods, CRUD & Idempotency

Most of a REST API is create, read, update, and delete over resources. The art is mapping those operations onto HTTP methods so that clients, proxies, and your own retry logic all behave correctly.

CRUD to HTTP

Section titled “CRUD to HTTP”
flowchart LR
  Create -->|POST /articles| C[201 Created]
  Read -->|GET /articles or /articles/42| R[200 OK]
  Update -->|PUT or PATCH /articles/42| U[200 OK]
  Delete -->|DELETE /articles/42| D[204 No Content]
The conventional mapping from CRUD to HTTP methods

The mapping is not arbitrary: each method carries guarantees about safety (does it mutate?) and idempotency (is repeating it the same as doing it once?). Those guarantees are what let a client safely retry a dropped request, or a proxy cache a response.

What this module covers

Section titled “What this module covers”
  • GET & POST — reading safely and creating resources.
  • PUT, PATCH & DELETE — replacing, partially updating, and removing.
  • Idempotency & safety — the properties that make retries safe.
  • Bulk & async — batch operations and long-running work.
Which HTTP method conventionally creates a new resource in a collection?
A successful DELETE that returns no body typically uses which status?