Methods & Idempotency

HTTP methods map to semantics

Resources live at URLs; methods say what you want to do to them. Interviewers expect you to map CRUD and common actions to verbs without defaulting everything to POST.

Safe methods should not change server state in ways that matter for the operation (logging and metrics aside). Do not use GET to delete or charge a card — caches, prefetchers, and crawlers may replay GET.

Typical CRUD mapping

GET    /orders/42          → 200 + order representation
GET    /orders             → 200 + collection (paginated)
POST   /orders             → 201 + Location: /orders/43
PUT    /orders/42          → 200 or 204 (full replace)
PATCH  /orders/42          → 200 (partial update)
DELETE /orders/42          → 204 (or 404 if already gone)

POST creates when the server assigns the id. PUT to a known URI is “create or replace at this URL” — idempotent if repeated with the same body.

PATCH semantics vary by API: JSON Merge Patch, JSON Patch, or ad hoc partial fields. Document whether PATCH is idempotent (applying the same patch twice yields the same state).

Idempotency

Idempotent means: applying the same operation again does not compound unintended effects beyond the first successful application.

Why it matters: clients, proxies, and gateways retry on timeouts. If the first request actually succeeded but the response was lost, a retry must not create a second charge or a duplicate order.

Idempotent by HTTP definition

• GET, HEAD, OPTIONS — read-only; safe to repeat.
• PUT — replacing /orders/42 with the same body twice leaves one resource in the same state.
• DELETE — deleting the same resource twice: first returns 204, second often 404 — both acceptable idempotent outcomes if your spec says so.

POST is not idempotent by default

Two POST /orders with the same body typically create two orders. For payments, transfers, and other side-effect-heavy creates, use idempotency keys (see Versioning, Pagination & Idempotency):

POST /payments
Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000

The server stores key → response for a TTL; duplicates return the same outcome.

PATCH and idempotency

If PATCH means “set status to shipped,” repeating it is idempotent. If PATCH means “increment retry_count,” it is not. State your policy in API docs.

When POST is the right read

Heavy search with a complex body sometimes uses POST /search or POST /orders/query instead of an enormous query string. That sacrifices cache-friendly GET but keeps URLs readable. Acknowledge the trade-off in interviews: GET for simple filters; POST when the query payload is large or structured.

Conditional requests

PUT and DELETE often pair with If-Match (ETag) or If-Unmodified-Since to avoid lost updates. Failure returns 412 Precondition Failed or 428 Precondition Required if you require clients to send validators. This pattern appears in optimistic concurrency discussions.

Interview framing

“What is idempotency?” — Repeating the same request does not multiply side effects. GET, PUT, DELETE are idempotent in HTTP semantics; POST is not unless you add idempotency keys or design create-with-client-id via PUT.

“PUT vs PATCH?” — PUT replaces the full resource; PATCH applies a partial change. PATCH is smaller on the wire; PUT is simpler to reason about for full-document updates.

“Why not POST everything?” — You lose safe caching on reads, clear intermediary behavior, and standard semantics that monitoring and client libraries understand.

Next: Statelessness — what the server is allowed to remember between requests.