Methods & Semantics
curl -X POST and curl -X GET hit the same URL, and only the letters after -X change on the wire. Yet a dropped connection turns one into a free retry and the other into a gamble.
- ▸One cell of the grid stays empty forever: anything read-only can be repeated for free, so nothing lands there.
- ▸A dropped reply is not a dropped request: resend a POST and you charge twice; resend a PUT, nothing moves.
- ▸Change GET to DELETE and one token flips on the wire, yet caches, retries, and routers all treat it differently.
Eight method names, two yes/no questions, and the grid fills in, except one square stays empty no matter which method you drop into it. The first question: is the method safe, its defined semantics read-only, a promise to leave the resource alone? The second: is it idempotent, so sending it twice leaves the server exactly where sending it once would?
GET, HEAD, OPTIONS, and TRACE all answer yes to both. POST and PATCH answer no to both: POST hands the resource your data to process however it likes, so two sends can mean two rows, and a PATCH like increment-by-one changes the resource again on every repeat. PUT and DELETE sit in between, a repeat changes nothing past the first send, so they are idempotent, yet that first send is a write, so they are not safe.
The empty square is the whole point. No method is safe but not idempotent, because a request that changes nothing can be repeated forever and still change nothing: read-only forces repeat-safe. The four-corner grid you expected has only three live corners, and every method the protocol defines falls into one of them.