HTTP Methods Reference
Quick card per HTTP method (GET, POST, PUT, DELETE, PATCH, …) — safety, idempotence, cacheability, and whether request / response bodies are allowed.
Retrieve a representation of a resource. Should have no side effects.
- Safe
- Yes
- Idempotent
- Yes
- Cacheable
- Yes
- Req body
- No
- Res body
- Yes
Like GET but with no response body. Used to inspect headers (size, ETag, Last-Modified).
- Safe
- Yes
- Idempotent
- Yes
- Cacheable
- Yes
- Req body
- No
- Res body
- No
Submit data to the server — create a new resource, send a form, or trigger a side-effecting action. Cacheable only when explicit Cache-Control / Expires headers permit.
- Safe
- No
- Idempotent
- No
- Cacheable
- Maybe
- Req body
- Yes
- Res body
- Yes
Replace the target resource entirely with the request payload. Calling it twice gives the same result as once.
- Safe
- No
- Idempotent
- Yes
- Cacheable
- No
- Req body
- Yes
- Res body
- Yes
Remove the target resource. Idempotent in the same sense as PUT — deleting an already-gone resource still ends with the same state.
- Safe
- No
- Idempotent
- Yes
- Cacheable
- No
- Req body
- Maybe
- Res body
- Yes
Apply a partial update to the resource. RFC 5789 leaves the patch format up to the API — JSON Patch (RFC 6902) and JSON Merge Patch (RFC 7396) are the common choices.
- Safe
- No
- Idempotent
- No
- Cacheable
- No
- Req body
- Yes
- Res body
- Yes
Ask what the server supports for the target — methods, CORS preflight, accepted Content-Types. The response usually carries an Allow header.
- Safe
- Yes
- Idempotent
- Yes
- Cacheable
- No
- Req body
- No
- Res body
- Yes
Echo back the request as the server sees it after proxies. Usually disabled in production for security (Cross-Site Tracing).
- Safe
- Yes
- Idempotent
- Yes
- Cacheable
- No
- Req body
- No
- Res body
- Yes
Establish a tunnel to the server, used by HTTP proxies for HTTPS. The client and server exchange raw bytes after the proxy accepts.
- Safe
- No
- Idempotent
- No
- Cacheable
- No
- Req body
- No
- Res body
- No
"Maybe" means the property holds only under explicit headers (Cache-Control on POST, body on DELETE).
How to use
- Type a method name (
patch) or a keyword (cache,tunnel) to filter. - Read the per-method card: description on top, the five property dots underneath.
- Click copy to drop the method into your fetch call or curl command.
About this tool
ShowHide
A card per HTTP method covering the four properties that actually shape an API: safe, meaning it changes nothing on the server; idempotent, meaning repeating it leaves the same end state; cacheable; and whether a body is allowed on the request and the response. The relationship between the first two is the part people get backwards. Safe implies idempotent, but not the other way round: DELETE is idempotent because deleting twice leaves the resource just as gone, yet it is certainly not safe. And idempotent is a statement about server state, not about the reply — a second DELETE returning 404 where the first returned 204 is entirely correct, which matters when you decide whether a client may safely retry a request that timed out.
Frequently asked questions
Why does PATCH have its own method when POST could do the same?
Semantics. PATCH means "apply this partial diff"; POST is "create or process this payload". Calling PATCH twice should leave the resource the same as calling it once if your patch format is well-designed; that idempotency guarantee is worth the extra verb.
Is POST really cacheable?
Conditionally — RFC 9111 §3 permits POST responses to be cached when the response carries explicit Cache-Control / Expires headers. In practice almost no one does this, so most caches treat POST as uncacheable.
Is DELETE still idempotent if the second call returns 404?
Yes. Idempotence describes the state of the server after the request, not the status code that comes back. Delete once and the resource is gone; delete again and it is still gone — the same end state, with the 404 simply reporting what was already true. The same reasoning applies to a PUT that returns 200 the first time and 200 again with no change.
My search query is too long for a URL. Should I switch to POST?
GET describes a search correctly — it is safe, cacheable and shareable — but URLs have practical length limits in servers, proxies and logs, and filters placed in a URL end up written to every access log along the way. POST is the pragmatic answer when the query is genuinely large or sensitive, at the cost of caching and of a link someone can send to a colleague.
Related tools
HTTP Headers Reference
Searchable reference for ~50 standard HTTP request, response, CORS, caching, security, and cookie headers.
Developer
HTTP Status Code Reference
Searchable list of every HTTP status code (1xx-5xx) with summary, RFC, when to use, and common pitfalls.
Network
Git Config Precedence Tester
Paste your git config files and see which value wins for every key, the scope, file and line it came from, what it overrode, and which includeIf fired.
Developer
Base64 Encoder / Decoder
Encode text to Base64 or decode Base64 back to text, instantly.
Developer
Python Pickle Inspector
Disassemble a .pkl file in the browser: every opcode, the memo, the value it rebuilds, and whether loading it would run code.
Developer
HTTP Cookie Parser
Paste a Cookie: request header or a Set-Cookie: response header and see each cookie's name, value, attributes, and warnings.
Developer