Por que PATCH tem método próprio se POST poderia fazer o mesmo?

Semântica. PATCH significa "aplique esse diff parcial"; POST é "crie ou processe esse payload". Chamar PATCH duas vezes deveria deixar o recurso igual a chamá-lo uma se seu formato de patch é bem desenhado; essa garantia de idempotência vale o verbo extra.

POST realmente é cacheable?

Condicionalmente — RFC 9111 §3 permite cachear responses POST quando a resposta carrega headers explícitos `Cache-Control` / `Expires`. Na prática quase ninguém faz isso, então maioria dos caches trata POST como não cacheable.

Referência de Métodos HTTP

Desenvolvimento

As quatro propriedades que realmente moldam design de API — safe (sem efeitos colaterais server-side), idempotente (mesmo estado final em N repetições), cacheable (response reutilizável), e body-bearing (request e response) — coletadas por método, com resumo de uma linha de quando cada um é apropriado.

—

GET

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

Safe: Sim
Idempotente: Sim
Cacheable: Sim
Req body: Não
Res body: Sim

HEAD

Like GET but with no response body. Used to inspect headers (size, ETag, Last-Modified).

Safe: Sim
Idempotente: Sim
Cacheable: Sim
Req body: Não
Res body: Não

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: Não
Idempotente: Não
Cacheable: Talvez
Req body: Sim
Res body: Sim

PUT

Replace the target resource entirely with the request payload. Calling it twice gives the same result as once.

Safe: Não
Idempotente: Sim
Cacheable: Não
Req body: Sim
Res body: Sim

DELETE

Remove the target resource. Idempotent in the same sense as PUT — deleting an already-gone resource still ends with the same state.

Safe: Não
Idempotente: Sim
Cacheable: Não
Req body: Talvez
Res body: Sim

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: Não
Idempotente: Não
Cacheable: Não
Req body: Sim
Res body: Sim

OPTIONS

Ask what the server supports for the target — methods, CORS preflight, accepted Content-Types. The response usually carries an Allow header.

Safe: Sim
Idempotente: Sim
Cacheable: Não
Req body: Não
Res body: Sim

TRACE

Echo back the request as the server sees it after proxies. Usually disabled in production for security (Cross-Site Tracing).

Safe: Sim
Idempotente: Sim
Cacheable: Não
Req body: Não
Res body: Sim

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: Não
Idempotente: Não
Cacheable: Não
Req body: Não
Res body: Não

"Talvez" significa que a propriedade só vale com headers explícitos (Cache-Control em POST, body em DELETE).

Como usar

Digite um nome de método (`patch`) ou palavra-chave (`cache`, `tunnel`) pra filtrar.
Leia o cartão por método: descrição em cima, os cinco pontos de propriedades embaixo.
Clique copiar pra colocar o método na sua chamada fetch ou comando curl.

Perguntas frequentes

Por que PATCH tem método próprio se POST poderia fazer o mesmo?: Semântica. PATCH significa "aplique esse diff parcial"; POST é "crie ou processe esse payload". Chamar PATCH duas vezes deveria deixar o recurso igual a chamá-lo uma se seu formato de patch é bem desenhado; essa garantia de idempotência vale o verbo extra.
POST realmente é cacheable?: Condicionalmente — RFC 9111 §3 permite cachear responses POST quando a resposta carrega headers explícitos `Cache-Control` / `Expires`. Na prática quase ninguém faz isso, então maioria dos caches trata POST como não cacheable.