HTTP

In one line

The verbs, headers, body, cookies and status codes that every API contract is written in.

0/10 · 0%

Think of it like this

Filling a form at a government office. GET is 'just show me the form', POST is 'submit a new form', PUT is 'replace my old form completely', DELETE is 'throw my form away'. The status code (like 404) is the stamp the clerk puts on your receipt telling you what happened.

Key ideas

01
Verbs: GET (read, cacheable, safe), POST (create/action, non-idempotent), PUT (replace, idempotent), PATCH (partial update), DELETE (remove, idempotent).
02
Idempotency: same call, same result. GET/PUT/DELETE idempotent; POST is not — that's why payment retries key on POST + idempotency key.
03
Headers: Authorization, Content-Type, Accept, Cache-Control, Retry-After, X-Request-Id (trace!).
04
Body: JSON/XML/form; GET has no body; that's a smell when someone tries to GET-with-payload.
05
Cookies: small server-issued tokens the browser echoes; session identity for classic apps.
06
Status codes to know cold: 2xx (200 OK, 201 Created, 204 No Content), 3xx (301/302 redirect, 304 Not Modified), 4xx (400, 401, 403, 404, 409, 429), 5xx (500, 502, 503, 504).
07
HTTP/1.1 vs 2 (multiplexing, HPACK) vs 3 (QUIC over UDP) — mention when talking latency.

Java / Spring map

→
Spring Web: @GetMapping/@PostMapping; ResponseEntity status; ClientHttpRequestInterceptor for X-Request-Id.

Code & diagrams

HttpContract.mdmarkdown

The status-code cheat sheet to internalize.

200 OK                 — success
201 Created            — resource created
204 No Content         — success, nothing to return
301/302                — permanent/temporary redirect
304 Not Modified       — cached copy is fresh (ETag/If-None-Match)
400 Bad Request        — malformed body/params
401 Unauthorized       — not authenticated
403 Forbidden          — authenticated but not allowed
404 Not Found          — resource does not exist
409 Conflict          — state conflict (version, duplicate)
429 Too Many Requests — rate limited (send Retry-After)
500 Internal Error     — server bug
502 Bad Gateway        — upstream returned garbage
503 Service Unavailable— overloaded / draining
504 Gateway Timeout    — upstream too slow

Idempotent: GET, PUT, DELETE, HEAD
Not idempotent: POST (add an idempotency key for retries)

Explain without notes

Why is POST the only verb that needs an idempotency key for payment retries?

Practice

Write the HTTP contract for 'place parking reservation': verbs, paths, status codes, Retry-After placement.

Trade-offs

↔
PATCH semantics are ambiguous across implementations; PUT with full state is simpler to reason about.

Run it in production

You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:

Networking · HTTP on the wire

Methods, status codes, and headers in raw curl -v output.

Networking · Cookies, sessions & caching

Cache-Control, ETags, and where sessions should live.

Networking · HTTP/1.1 vs 2 vs 3

Multiplexing, QUIC, and why gRPC needs L7 load balancing.

Completion checklist

I can answer 'design the API for X' with verbs+status codes without hesitation.

Back to phase

Command Palette