GET vs POST vs PUT vs PATCH vs DELETE — how do you choose?
Take a moment.
Say your answer out loud or write it down first — retrieval is what makes it stick. Reveal when you're ready.
Short answer
GET reads data (safe, cacheable, no body semantics). POST creates or triggers actions (neither safe nor idempotent). PUT replaces a whole resource, PATCH applies a partial update (both idempotent), DELETE removes one (idempotent). Choose by the operation's semantics, not just CRUD habit.
Detailed explanation
HTTP methods carry meaning that caches, browsers, and APIs all rely on. Safe methods (GET, HEAD) must not change server state — that's why browsers freely retry, prefetch, and cache them, and why a GET must never perform a delete or charge. Idempotent methods (GET, PUT, DELETE) produce the same server state whether sent once or five times, so clients and proxies can safely retry them after network failures; POST and PATCH are generally not idempotent (posting twice creates two orders — unless the API adds idempotency keys). Conventions: GET /users/7 reads one user; POST /users creates (server assigns the id, returns 201 + Location header); PUT /users/7 replaces the entire record (client supplies the id, missing fields reset); PATCH /users/7 updates only the sent fields; DELETE /users/7 removes it. Status codes pair with the choice: 200 for success with a body, 201 for creation, 204 for success with no body, 400 for bad input, 404 for unknown ids, 409 for conflicts. Getting this right makes retries safe, caching automatic, and APIs predictable.
Example
GET /users/7 # read (safe, retryable, cacheable)
POST /users # create → 201 Created, Location: /users/8
PUT /users/8 # replace whole record (idempotent)
PATCH /users/8 # { "email": "b@x.com" } — partial update
DELETE /users/8 # remove (idempotent: deleting twice = same state)
# Retry-safe only with idempotency:
# POST /charges { amount: 100 } twice → charged twice!
# Fix: POST /charges with Idempotency-Key: abc-123 → second send returns the originalInterview tip
Lead with the two words — safe and idempotent — and which methods have each property. The double-charge POST example proves you think about real failure modes.
Common mistakes
- Using GET for state-changing actions because it is convenient.
- Calling POST idempotent or forgetting PUT/PATCH/DELETE are retry-safe.
- Returning 200 for everything instead of 201/204/400/404.