¿Por qué PATCH tiene su propio método si POST podría hacer lo mismo?

Semántica. PATCH significa "aplica este diff parcial"; POST es "crea o procesa este payload". Llamar PATCH dos veces debería dejar el recurso igual que llamarlo una si tu formato de patch está bien diseñado; esa garantía de idempotencia vale el verbo extra.

¿POST es realmente cacheable?

Condicionalmente — RFC 9111 §3 permite cachear respuestas POST cuando la respuesta lleva headers explícitos `Cache-Control` / `Expires`. En la práctica casi nadie hace esto, así que la mayoría de caches tratan POST como no cacheable.

Referencia de Métodos HTTP

Desarrollo

Las cuatro propiedades que realmente moldean el diseño de API — safe (sin efectos secundarios server-side), idempotente (mismo estado final en N repeticiones), cacheable (respuesta reusable), y body-bearing (petición y respuesta) — recolectadas por método, con resumen de una línea de cuándo cada uno es apropiado.

—

GET

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

Safe: Sí
Idempotente: Sí
Cacheable: Sí
Req body: No
Res body: Sí

HEAD

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

Safe: Sí
Idempotente: Sí
Cacheable: Sí
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
Idempotente: No
Cacheable: Tal vez
Req body: Sí
Res body: Sí

PUT

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

Safe: No
Idempotente: Sí
Cacheable: No
Req body: Sí
Res body: Sí

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
Idempotente: Sí
Cacheable: No
Req body: Tal vez
Res body: Sí

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
Idempotente: No
Cacheable: No
Req body: Sí
Res body: Sí

OPTIONS

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

Safe: Sí
Idempotente: Sí
Cacheable: No
Req body: No
Res body: Sí

TRACE

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

Safe: Sí
Idempotente: Sí
Cacheable: No
Req body: No
Res body: Sí

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
Idempotente: No
Cacheable: No
Req body: No
Res body: No

"Tal vez" significa que la propiedad solo se cumple bajo headers explícitos (Cache-Control en POST, body en DELETE).

Cómo usar

Escribe un nombre de método (`patch`) o palabra clave (`cache`, `tunnel`) para filtrar.
Lee la tarjeta por método: descripción arriba, los cinco puntos de propiedades debajo.
Pulsa copiar para meter el método en tu llamada fetch o comando curl.

Preguntas frecuentes

¿Por qué PATCH tiene su propio método si POST podría hacer lo mismo?: Semántica. PATCH significa "aplica este diff parcial"; POST es "crea o procesa este payload". Llamar PATCH dos veces debería dejar el recurso igual que llamarlo una si tu formato de patch está bien diseñado; esa garantía de idempotencia vale el verbo extra.
¿POST es realmente cacheable?: Condicionalmente — RFC 9111 §3 permite cachear respuestas POST cuando la respuesta lleva headers explícitos `Cache-Control` / `Expires`. En la práctica casi nadie hace esto, así que la mayoría de caches tratan POST como no cacheable.