9 HTTP Request Methods
HTTP methods and their safety, idempotency, and resource update semantics.
HTTP methods define intent, not just routing. Their semantics affect caching, retries, browser behaviour, proxies, and client assumptions. Two properties matter throughout: a method is safe when it should not mutate state, and idempotent when repeating the same request has the same intended effect as sending it once. That is why method selection is part of contract design, not a naming preference.
GET
GET retrieves a representation of a resource. It is safe and idempotent, which is why caches and browsers handle it aggressively. A GET endpoint that performs writes breaks prefetching, retry safety, and client expectations.
POST
POST submits data for server-side processing and is commonly used for creation or commands. It is not inherently idempotent, so duplicate submission after a timeout can create duplicate work unless the application adds idempotency keys or deduplication.
PUT
PUT replaces the state of the target resource with the supplied representation. It is idempotent, but only if the contract is clear. The usual mistake is using PUT for partial updates without defining what omitted fields mean.
PATCH
PATCH applies a partial modification. It is useful when sending only changed fields is cheaper or clearer than full replacement. Whether it is idempotent depends on the patch operation: "set status to closed" can be idempotent, while "increment by 1" is not.
DELETE
DELETE removes the target resource and is idempotent in the HTTP sense. Repeating it should not create a new side effect, even if later responses differ, such as 204 on the first call and 404 on a repeat.
HEAD
HEAD returns the headers a GET would return, but without the body. It is useful for metadata checks such as content length, cache validation, or existence probing. A poor implementation that still generates the full body wastes the optimisation.
OPTIONS
OPTIONS describes the communication options for a resource. Browsers rely on it for CORS preflight checks, and servers can use it to advertise allowed methods through headers such as Allow. Trouble starts when the preflight policy and the real handler do not agree.
CONNECT
CONNECT asks an intermediary to open a tunnel to the target server. It is most often seen when an HTTP proxy tunnels HTTPS traffic. Application developers rarely implement it directly, but understanding it helps explain proxy and enterprise network behaviour.
TRACE
TRACE performs a loop-back diagnostic request so the client can see what intermediaries changed. It exists in the standard, but many production systems disable it because reflecting headers can expose sensitive information or support cross-site tracing attacks.
Method choice is part of API design
When method semantics match actual behaviour, caches work better, retries become safer, and clients stay simpler. When they do not, every caller, proxy, and browser along the path has to guess what your API really means.