A `PUT` request that quietly creates a resource on its first call and simply updates it on a retry looks identical from a monitoring dashboard whether it ran once or three times — right up until it wasn't, and a client library's automatic retry on a bare `POST` created the same order twice because a load balancer timed out waiting for a response that had actually already succeeded. The decisions this lesson covers — which HTTP method, which status code — read like a vocabulary problem, something you look up once in a table and never think about again. They are not. They are the actual mechanism by which a piece of infrastructure that has never seen your business logic — a load balancer, a retrying SDK, a message queue — can decide, correctly and automatically, whether it's safe to resend a failed request. Get the vocabulary wrong and that decision gets made wrong, invisibly, until the exact moment a network hiccups in production.
Most engineers can recite that GET is for reading and DELETE is for deleting; the actual failure mode in this lesson lives one level deeper, in three specific places teams consistently get subtly wrong: conflating "idempotent" with "has no side effects" as though they were the same guarantee, reaching for `200 OK` on every success regardless of what kind of success it was, and treating `PATCH` as though the method name alone told a server how to interpret a partial request body. None of these mistakes look wrong in a code review. All three become real incidents the first time a network behaves the way real networks actually behave.
This lesson works through the distinction between safety and idempotency precisely enough to apply under pressure, the concrete difference between `200`, `201`, `202`, and `204` and when each is the honest choice, and why `PATCH` cannot be implemented correctly without first choosing, explicitly, what its request body actually means.