HTTP Methods Reference
The four properties that actually shape API design — safe (no server-side side effects), idempotent (same end state on N repeats), cacheable (response can be reused), and body-bearing (request and response) — collected per method, with a one-line summary of when each one is appropriate.
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.
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.
Related tools
HTTP Headers Reference
Searchable reference for ~50 standard HTTP request, response, CORS, caching, security, and cookie headers.
HTTP Status Code Reference
Searchable list of every HTTP status code (1xx-5xx) with summary, RFC, when to use, and common pitfalls.
Base64 Encoder / Decoder
Encode text to Base64 or decode Base64 back to text, instantly.
HTTP Cookie Parser
Paste a `Cookie:` request header or a `Set-Cookie:` response header and see each cookie's name, value, attributes, and warnings.
ASCII Code Table
Browse and search the 256-row ASCII / extended-ASCII table — decimal, hex, octal, binary, and the named control characters.
MIME Type Lookup
Find the MIME type for a file extension (or the other way around) and learn what each type is for.