También disponible en: English · Português · Français · العربية
Métodos HTTP: seguros, idempotentes y cacheables
Todos los métodos que IANA tiene registrados, y lo que cada uno significa para un rastreador, un proxy y una caché.
¿Qué es un método HTTP?
Un método HTTP —el verbo con el que arranca una petición, GET o POST o DELETE— dice qué quiere hacer el cliente con el recurso que nombra. Hay muchos más de los que uno se cruza a diario: el registro de IANA guarda 41 nombres y solo nueve vienen de la especificación central de HTTP. El resto llega de WebDAV, de las extensiones de versionado, de CalDAV, de HTTP/2 y de tres especificaciones sueltas.
El RFC 9110 da tres propiedades a cada método. Es seguro si su semántica es esencialmente de solo lectura, de modo que un rastreador puede lanzarlo sin miedo. Es idempotente si enviar la misma petición dos veces surte el mismo efecto que enviarla una, de modo que un proxy puede reintentarla tras una conexión caída. Y es cacheable si una caché puede guardar la respuesta y reutilizarla más tarde.
Esas tres respuestas son lo que debería darte una página sobre métodos HTTP, y no viven todas en el mismo sitio: ese es el motivo de esta página, en lugar de una copia del registro.
Cómo usarla
- Escribe el nombre de un método. Da igual las mayúsculas. Obtienes las tres propiedades, lo que significa cada una en la práctica para un cliente y para una caché, y un enlace a la sección del RFC que lo dice.
- O busca en todo el registro. La tabla de abajo tiene los 41 nombres. Buscar un número de RFC —9110, 4918— devuelve todo lo que define ese documento.
- Redúcela a los que vas a encontrarte de verdad. Una casilla deja la tabla en los nueve nombres que registra el propio RFC 9110, que son todos los métodos que envía la mayoría de las API.
La propiedad que el registro no anota
La sección 16.1.1 del RFC 9110 enumera los campos que debe llevar el registro de un método: el nombre, si es seguro, si es idempotente y un puntero a la especificación. Cuatro campos, y la cacheabilidad no está entre ellos. Sin embargo, la sección 16.1.2 del mismo documento dice que la definición de un método nuevo tiene que indicar si es seguro, idempotente y cacheable. Tres propiedades nombradas con una sección de diferencia, dos de ellas apuntadas.
Así que la tercera hay que leerla en los documentos que definen cada método, y son trece. Al hacerlo salen respuestas limpias para casi todas las filas y una incómoda para el resto: 3 métodos son cacheables sin más, otros 3 solo bajo condiciones explícitas, 26 no lo son en absoluto y 9 especificaciones no mencionan el caché en ningún momento.
Ese silencio no es una incógnita, y esta es la frase que hace la tabla completa en vez de parcial. Sección 9.2.3: para que una caché guarde y use una respuesta, el método tiene que permitir el cacheo explícitamente y detallar en qué condiciones, y un método cuya definición no lo hace no puede cachearse. El silencio es un no por defecto, escrito en el propio estándar. Aun así la tabla muestra esas nueve filas como «no se dice» y no como «no», porque lo que una especificación prohíbe y lo que nunca se planteó son hechos distintos y solo uno de ellos se puede citar en una revisión de código.
Las fórmulas también difieren, y merece la pena verlas. Ocho métodos dicen que las respuestas NO DEBEN cachearse, lo que obliga a la caché. Diez —la familia de versionado, más MKCALENDAR— exigen en cambio que el servidor envíe Cache-Control: no-cache, lo que obliga al servidor. SEARCH solo dice NO DEBERÍAN. PROPFIND dice que los resultados pueden cachearse, con cuidado. La tabla registra qué fórmula produjo cada respuesta.
Las filas que todo el mundo falla
PATCH no es idempotente. Aparece junto a PUT en todos los tutoriales de REST y se comporta distinto: aplicar el mismo parche dos veces puede no equivaler a aplicarlo una, así que el registro lo anota como ni seguro ni idempotente, y el RFC 9110 dice que un proxy no debe reintentar automáticamente una petición así. DELETE, en cambio, sí es idempotente pese a sonar al verbo más destructivo de la lista: borrar algo dos veces lo deja borrado.
Seguro no significa cacheable. Nueve métodos son seguros y solo tres —GET, HEAD y QUERY— son cacheables sin condiciones. OPTIONS y TRACE son de solo lectura y sus respuestas nunca se cachean, dicho explícitamente. REPORT es seguro, idempotente y su especificación no dice absolutamente nada sobre el caché.
Y falla también al revés: POST y PATCH no son seguros ni idempotentes, y ambos son cacheables bajo condiciones. Una respuesta a POST puede guardarse si lleva información explícita de frescura y un Content-Location que coincida con el destino de la petición, y entonces solo puede servir para responder a un GET o HEAD posterior, nunca a otro POST. El RFC 9110 comenta de pasada que, en cualquier caso, la inmensa mayoría de las cachés solo implementan GET y HEAD, que es una especificación admitiendo que la realidad se le fue por otro lado.
Dos curiosidades más. QUERY es método de vía estándar desde junio de 2026: seguro, idempotente, cacheable y con cuerpo en la petición, justo lo que la gente ha querido cada vez que ha intentado meter una búsqueda larga en un GET. Su clave de caché debe incorporar el cuerpo, que es exactamente por lo que tardó tanto en llegar. Y el registro contiene una entrada llamada simplemente asterisco, que no es un método: está reservada para que nadie pueda registrar uno con ese nombre, porque chocaría con el comodín de cabeceras como Access-Control-Request-Method.
Lo que esta página no puede decirte
Estas son propiedades del método, no promesas sobre un servidor. Un servidor puede implementar GET de modo que borre algo; la especificación deja claro que eso convierte al servidor en incorrecto, no a GET en inseguro. Lo que compran las propiedades es el derecho a suponer: un rastreador precargando métodos seguros, un proxy reintentando los idempotentes, una caché guardando los cacheables, sin pedirle permiso a nadie.
La tabla es además la foto de un registro que crece. QUERY se añadió en 2026 y aquí no se predice qué vendrá después. Donde una fila dice que una especificación calla, eso describe el documento tal como está hoy, no una promesa de que seguirá callando.
Y que un método esté registrado no dice nada sobre si algo lo admite. La mayoría de estos 41 nombres pertenecen a WebDAV y sus extensiones, y un servidor web normal los responderá con un 405.
¿Por qué es gratis?
El registro entero son unos pocos kilobytes que viajan con la página y se consultan en tu navegador. Nada de lo que escribes se sube, no se registra nada y no hay cuenta que crear.
Sin registro, sin límites y sin marca de agua en nada de lo que copies.