Choose an HTTP method by its semantics

Choose methods from their defined semantics and understand why retries and redirects treat them differently.

  • methods
  • safety
  • idempotency

A method states what the client is asking the target to do

The method token is part of the request semantics. GET asks for a current representation of a resource, HEAD asks for the same response metadata without response content, and POST asks the target resource to process enclosed content according to its own semantics.

That contract is more precise than mapping methods mechanically to database operations. A resource can compute a representation without a database, and a POST can create, append, trigger, or process depending on the target.

GET /reports/today HTTP/1.1
Host: example.invalid

Expected result: the request asks for a representation of the selected resource. It does not ask the server to “read a database row,” even if that is how one implementation produces the response.

Safety describes requested intent

A safe method has read-only semantics: the client does not request a state change at the origin. Logging, billing, cache population, or other incidental effects can still occur. Safety is a contract for how clients and automated agents can use a method, not a claim that the server performs no work.

GET and HEAD are safe. POST is not. Putting a destructive action behind a GET target breaks the method contract and can let crawlers, prefetchers, or caches trigger behavior the application did not expect.

Idempotency is about repeating the intended effect

An idempotent method has the same intended effect when an identical request is made once or several times. The response can still differ: timestamps, status, metrics, or the current representation can change.

Idempotency helps a client or intermediary reason about automatic retries after a connection failure. It does not prove that retrying is always safe for a specific application, and an idempotency key on POST is an application contract rather than a change to the method’s general semantics.

Request content is method-specific

Do not assume every method treats content alike. A method definition states what request content means and whether it has generally defined semantics. When a framework accepts an unusual combination, interoperability still depends on clients, intermediaries, and servers sharing that meaning.

Primary sources