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.

HTTP Methods Reference

Developer

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.

—

GET

Retrieve a representation of a resource. Should have no side effects.

Safe: Yes
Idempotent: Yes
Cacheable: Yes
Req body: No
Res body: Yes

HEAD

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

POST

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

PUT

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

DELETE

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

PATCH

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

OPTIONS

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

TRACE

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

CONNECT

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.