The verb is a promise
The method is a promise about side effects. GET promises to read without changing anything, so caches and prefetchers can fire it freely. POST creates or triggers something. PUT replaces a resource outright, PATCH edits part of it, and DELETE removes it.
Idempotency is worth learning properly, because it is the property that matters here. An operation is idempotent when calling it twice leaves the system exactly as calling it once did. GET, PUT and DELETE promise this. POST does not, and that sounds academic until a phone on a bad connection times out, retries, and your handler charges a customer twice.
An idempotency key fixes it: an identifier the client generates and sends, which the server uses to recognise a duplicate and return the original result instead of acting again. Stripe's API is the well known version. Send the same key twice and the second attempt hands back the first charge rather than making a second one.
Status codes are the other half
Status codes are the other half of the promise, and the first digit carries most of the meaning. 2xx worked. 3xx means look elsewhere, where 301 is permanent and 302 is temporary, and those two get mixed up constantly. 4xx means the caller got it wrong: 400 malformed, 401 not logged in, 403 logged in but not allowed, 404 missing, 429 slow down. 5xx means your server failed.
That split matters, because your own infrastructure acts on it. Retry policies repeat 5xx and 429 and never 400, since a malformed request will still be malformed on the tenth attempt. Load balancers pull servers out of rotation when 5xx spikes. Alerting pages someone on the 5xx rate. Return the wrong class and your tooling starts fighting you: a 500 where a 404 belonged can convince an autoscaler that healthy servers are dying.
Worked example
Dev's food delivery app sends POST /orders when a customer checks out. One evening a cell network hiccup causes his client library to retry on timeout, and a customer named Rohan gets billed twice for the same 24 dollar order, with two riders dispatched. The postmortem fix takes an afternoon: the app now generates a UUID per checkout attempt and sends it as an idempotency key. The server keeps those keys for 24 hours in Redis, an in-memory data store; a retry with a known key returns the stored response instead of creating a second order. The next month the logs show 1,900 duplicate submissions absorbed silently, roughly 0.4 percent of all orders, each one a double charge that never happened.