Every HTTP request opens with a verb, and that verb is a contract: it tells servers, caches, proxies, and retry logic what kind of thing is about to happen. Most of the web's plumbing does not read your URLs or your payloads - it reads your method and acts on the promises the method makes. This article is about those promises; the comparison tool puts them side by side.

The two properties that run the world

Safe means the request is read-only from the client's point of view: it asks for state, it does not change it. GET, HEAD, and OPTIONS are safe - which is precisely why crawlers may follow every link on your site, why prefetchers speculatively fire GETs, and why a "delete" action behind a GET link is a famous way to have a search-engine bot empty your database. Idempotent is the weaker, subtler promise: doing it N times leaves the same state as doing it once. All safe methods are idempotent; PUT and DELETE are idempotent without being safe (putting the same representation twice, or deleting the same resource twice, converges). POST promises neither - which is why your browser asks "resubmit form?" before replaying one, and why network middleware will silently retry a timed-out GET but never a timed-out POST. Retries, caching, and prefetching all key off these two bits.

The roster, briefly and honestly

GET retrieves a representation; HEAD is GET minus the body - same headers, no payload, the protocol's way of asking "how big, how fresh?" POST is the deliberately unpromising workhorse: process this payload according to the resource's own semantics - create something, trigger something, anything. PUT replaces the target with the enclosed representation (whole-resource, idempotent); PATCH applies a partial modification (and is not automatically idempotent - a patch that says "append X" proves it). DELETE removes; OPTIONS asks what is allowed - and gained a second career as CORS preflight's vehicle; TRACE echoes the request back (almost universally disabled); CONNECT asks a proxy to open a raw tunnel, which is how HTTPS traverses forward proxies. And the newest citizen, QUERY, exists to fix a real hole - safe, idempotent retrieval with a request body for queries too large or too structured for a URL - a story this site tells in full, including its BIG-IP handling.

Why forms only speak two verbs

A recurring surprise: HTML forms submit with GET or POST, full stop - the richer verbs belong to APIs called from code. That constraint shaped a generation of server frameworks (method-override headers, _method form fields) and is half the reason POST became the universal "do something" verb. The other half is inertia, which this site has written about before in another costume. How forms encode what they send is its own article.

When the answer never arrives

A timeout tells the client that it did not hear back, not that nothing happened: the request may have been carried out before the reply was lost. RFC 9110 draws the line exactly there. An idempotent request can be repeated automatically after a communication failure, and a client should not automatically repeat a non-idempotent one unless it has some way to know the request is idempotent anyway, or to detect that the original was never applied. For a POST that creates something, that leaves two honest options: look the object up by a stable identifier before trying again, or send the API's idempotency key, a value the client generates once per operation and repeats on every retry of it. The key is not HTTP semantics; it is a contract the API publishes, and the Internet-Draft that proposes an Idempotency-Key header field spells out what that contract needs: the resource says how long a key stays valid, a retry after the first request completed gets a response consistent with that completion, a retry while the first is still running gets 409 Conflict, and the same key sent with a different payload gets 422 rather than somebody else's result.

Two status codes belong to the same story. 202 Accepted means the request was accepted for processing and not yet completed, and its response ought to point at a status monitor: the operation is finished when the monitor says so, not when the 202 arrives (RFC 9110, section 15.3.3). And If-Match makes a change conditional on the entity tag the client last saw: if the resource has changed since, the server must not apply the request and may answer 412 Precondition Failed, or a 2xx when the requested change already appears to be in place, which is exactly the case of a retry whose first response was lost (RFC 9110, section 13.1.1). The retry, timeout and idempotency mechanics are taken apart, layer by layer, in Retries, timeouts and idempotency.

Reading an API by its verbs

The practical skill: an API's method discipline tells you its soul. Strict resource semantics (GET reads, PUT replaces, PATCH edits, DELETE removes, POST creates-under) signal a design you can cache, retry, and reason about; everything-is-POST signals RPC wearing HTTP as a transport - not wrong, but a different contract, where you now carry the idempotency bookkeeping the verbs would have carried for you. Either way, the verb line is the first line - of the request, and of the analysis.

Sources