The verbs of an API: asking for something, creating something, changing it, or deleting it are different actions on the same address.
Why it exists
The same address often needs to support more than one action: read this order, create a new one, change it, delete it. Treating every request identically would make it impossible to tell a harmless read from a change that charges a card. HTTP methods exist to name the action, so the system, and everyone reasoning about it, knows which requests are safe to repeat and which are not.
How it actually works
GET means read, and changes nothing. POST creates something new. PUT and PATCH update. DELETE removes. The same endpoint can behave differently depending on the verb used.
This distinction matters for safety. A GET can be repeated freely; a POST that charges a card cannot. Browsers, caches, and search engines all treat GET as safe to repeat and the others as not.
A senior PM walks you through it
A junior PM, stuck
A customer was charged twice for one Kacchi order. The dev said "the retry re-POSTed it" and moved on. I nodded, but I genuinely do not get why sending the same request again created a second order instead of just loading the first one.
It comes down to one word on each request: the method. A GET and a POST to the same address do opposite things when repeated, and the double charge is that difference in action. This is the same address, /api/orders, hit two ways: a GET sent three times, and the POST that got retried. Read both and the second charge explains itself.
/api/orders, same address, two methods
GET /api/orders, sent three times
112:41:032002
212:41:192002
312:41:442002
POST /api/orders, retried once after a network blip
413:07:112015512,649
513:07:142015513,649
Click a step to see the lines it points at.
Mistakes I've seen
Assuming a retry just re-loads the first result. A GET does; a POST re-runs the action, so a retried checkout creates a second order and a second charge.
Speccing a "resend" or "try again" button without asking the method. On a POST that money touches, resend means charge again unless the backend is built to catch the repeat.
Reading two orders with different ids as two customer actions. o_5512 and o_5513 came from one tap that got sent twice; the ids being different is exactly why the duplicate is easy to miss.
Thinking the safe-to-repeat rule is a nicety. Browsers, caches, and network retries all assume GET is safe and POST is not; break that and you get exactly this bug.
Explain it back as: "The retry re-sent a POST, and POST creates, so it made a second order o_5513 and charged 649 again. We need the backend to recognise the repeat." You read the method and named why repeating it cost money. That is the skill.
Where a PM meets this
"What method is it?" tells you whether an action is safe to retry. Payment and order actions are almost never GETs for exactly this reason.
Understanding read-versus-write helps you reason about which actions are risky to repeat.
Hear it in a meeting
"That should be a POST, not a GET, it's changing data."