HTTP Method Reference
GET / POST / PUT / DELETE — safe? idempotent? body?
Overview
The HTTP Method Reference summarises every standard HTTP method — GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, CONNECT, TRACE — and answers the three questions that come up every time a developer designs a REST endpoint: is it safe, is it idempotent, and is a body allowed on the request or response.
The reference is for API designers picking the right verb, backend engineers reviewing pull requests and front-end developers debugging unexpected behaviour. Long-tail queries it answers include "is PATCH idempotent", "can GET have a body", "difference between PUT and POST" and "HTTP method safety chart".
How it works
The data comes from RFC 9110 (HTTP Semantics), which is the authoritative specification for HTTP/1.1, HTTP/2 and HTTP/3 alike. Each row records whether the method is "safe" (does not change server state by intention), "idempotent" (calling it N times has the same effect as calling it once), whether a request body and response body are allowed, and whether responses can be cached.
The lookup is a static table rather than a calculator — these properties are fixed by specification, not derived. The tool exists to settle arguments and double-check API design choices in seconds.
Examples
GET → safe, idempotent, cacheable, response body, no request body (by convention)
POST → not safe, not idempotent, conditionally cacheable, body on both sides
PUT → not safe, idempotent, not cacheable, body on both sides
DELETE → not safe, idempotent, not cacheable, optional body
FAQ
Can GET have a request body?
The spec doesn't forbid it but caches, proxies and frameworks often strip it. Avoid sending GET request bodies — switch to POST or use query parameters.
Why is PATCH not idempotent?
PATCH applies a partial modification and the result can depend on the current state. A PATCH that increments a counter is the classic example: two PATCHes have a different effect from one. PATCH can be made idempotent by including a conditional header or a full new state.
What does "safe" mean exactly?
Safe means the method is not intended to change server state. GET, HEAD and OPTIONS are safe; everything else may have side effects. Safety is about intent, not enforcement — a sloppy implementation can break it.
Is DELETE idempotent if the resource is already gone?
Yes. Deleting an already-deleted resource has the same observable result as deleting it once: the resource is gone. The response status may differ (404 the second time), but the state is identical.
Why does HEAD exist?
HEAD returns the same headers as GET without the body. It's used to check if a resource exists, get a content length or test cache validity without paying for the download.