HTTP Semantics

Methods Carry Properties, Not Just Meaning

HTTP methods differ in three formal properties — and those properties are what load balancers, caches, and retry logic depend on:

Method	Safe	Idempotent	Cacheable	Contract
GET	✓	✓	✓	Read only; no state change
HEAD	✓	✓	✓	Headers of GET
PUT	✗	✓	✗	Replace resource at known URL
DELETE	✗	✓	✗	Remove; repeat = same end state
POST	✗	✗	✗	Create/process; each call may differ
PATCH	✗	not guaranteed	✗	Partial update; define your own idempotency

 SAFE     = read-only, crawlers/proxies may act freely
 IDEMPOTENT = calling N times ends in same state as once
              → THE property that makes retry-after-timeout safe
 CACHEABLE  = intermediaries may store and replay responses

Why Idempotency Is the Load-Bearing Property

Networks lose responses after servers acted. The caller cannot tell “failed” from “succeeded but reply lost”:

 retry PUT /trips/123 {status: completed}    → fine, idempotent
 retry POST /payments                        → DOUBLE CHARGE
 
 rule: retries are only safe over idempotent operations.
 POST-based money/state changes need explicit help:
   client-generated idempotency keys (own lesson later)

This single distinction explains why APIs route mutations through PUT/DELETE where possible, and why payment APIs invent keys.

Status Codes as a Protocol

Status classes carry meaning infrastructure acts on:

 2xx success        200 OK · 201 Created(+Location) · 202 Accepted(async) · 204 No Content
 3xx redirect       301 permanent · 302/307 temporary · 304 Not Modified(cache!)
 4xx CALLER's fault 400 malformed · 401 unauthenticated · 403 unauthorized
                     404 absent · 409 conflict · 422 semantic fail · 429 rate-limited
 5xx SERVER's fault 500 bug · 502 bad gateway · 503 overloaded(→ backoff!) · 504 timeout

The critical operational split:

• 4xx: retrying unchanged requests is pointless — fix the request.
• 5xx (esp. 503): retry with backoff is correct — server-side trouble is often transient.

Retry libraries, circuit breakers, and CDN behavior all branch on this class line. Returning 500 for validation errors makes clients’ retry logic poison.

Caching Semantics

 Cache-Control: max-age=300          fresh for 5 min, serve without asking
 ETag: "v37" + If-None-Match         revalidation → 304 saves payload bytes
 Vary: Authorization                 don't share cached body across users
 
 GET responses without cache headers = uncached by intermediaries;
 missing headers on public data is a free performance leak

Interview Framing

The interview probe is usually scenario-shaped: “client times out during payment creation — what happened and what should it do?” The scored answer walks properties: POST isn’t idempotent → state unknown → solution is idempotency key design, not blind retry. Knowing why methods behave as they do beats reciting tables.