🔧 A4 · HTTP Methods: GET / POST / PUT / PATCH / DELETE
A4 · HTTP Methods: GET / POST / PUT /: HTTP methods are the **action verbs** on a bug record; like moves on a filing cabinet: **GET** = open the folder and READ (changing nothing
HTTP methods are the **action verbs** on a bug record; like moves on a filing cabinet: **GET** = open the folder and READ (changing nothing), **POST** = ADD a new sheet, **PUT** = REPLACE the sheet entirely with a new one, **PATCH** = FIX a single line of the sheet, **DELETE** = THROW the sheet away. But if they all "touch data", why need separate verbs? Because each verb's **safety and repeatability** promise differs: GET is safe (call it 100 times, nothing changes), POST is NOT idempotent (call it twice, two records), while PUT/DELETE are idempotent (call five times, same result as once). In Java the equivalent is a method's side effect: `getBug()` is a pure reader, `createBug()` grows the list on every call, `deleteBug(id)` deletes on the first call and finds it already gone afterwards. The QA crux: if a "payment" endpoint is written with POST and the user double-clicks, without idempotency you get a **double charge** — the tester must hunt this class of bugs by "sending the same request twice".
Five Methods, Five Promises
🎬 The Double-Click Danger: Why POST Is Not Idempotent
The user impatiently clicks "Create Bug" TWICE. If it were GET there'd be no problem — but this is a POST.
The first POST reaches the server and creates a new bug (id: 42). So far so normal.
The second POST goes too — the server does NOT know it is the same request, because POST is not idempotent. It creates a second record (id: 43).
The result: the same bug was saved twice. On a payment endpoint this means a double charge — a silent but expensive bug.
The lesson — The tester hunts this bug class by "sending the same POST twice". If idempotency is needed, the developer should use PUT or an idempotency key.
PUT vs PATCH: Full Replace or One Line?
PUT replaces entirely…
PUT /api/v1/bugs/42 writes the ENTIRE body you send; a field you omit (e.g. severity) is DROPPED/reset.
PATCH fixes one field…
PATCH /api/v1/bugs/42/status changes only the status field; it does NOT touch the others.