← Back to API and Web Development

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 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.