Consulta cualquier método de petición HTTP registrado: qué hace, qué especificación lo define y si es seguro e idempotente. La tabla cubre los nueve métodos principales y las extensiones WebDAV, DeltaV y CalDAV.
Se ejecuta localmente en tu navegadorLos métodos de petición HTTP indican qué debe hacer una petición. Nueve métodos principales vienen del propio HTTP — GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE y PATCH —; el resto son extensiones registradas para WebDAV, versiones y calendarios, además de dos métodos que las revisiones posteriores de HTTP eliminaron. La tabla recoge todos los métodos del registro de métodos HTTP de la IANA con la especificación que los define y si son seguros e idempotentes.
| Método | Definido en | Seguro / idempotente | Propósito |
|---|---|---|---|
| Métodos principales | |||
| GET | RFC 9110 §9.3.1 | sí / sí | Obtiene una representación del recurso de destino. |
| HEAD | RFC 9110 §9.3.2 | sí / sí | Obtiene solo las cabeceras de la respuesta, sin el cuerpo. |
| POST | RFC 9110 §9.3.3 | no / no | Envía datos al recurso de destino para que los procese; a menudo crea un recurso o inicia una acción. |
| PUT | RFC 9110 §9.3.4 | no / sí | Crea el recurso de destino o lo reemplaza por el contenido de la petición. |
| DELETE | RFC 9110 §9.3.5 | no / sí | Elimina el recurso de destino. |
| CONNECT | RFC 9110 §9.3.6 | no / no | Abre un túnel hacia la autoridad de destino, normalmente a través de un proxy. |
| OPTIONS | RFC 9110 §9.3.7 | sí / sí | Pregunta qué métodos y opciones admite el recurso de destino. |
| TRACE | RFC 9110 §9.3.8 | sí / sí | Pide al servidor que devuelva la petición recibida para diagnosticarla. |
| PATCH | RFC 5789 §2 | no / no | Aplica al recurso de destino los cambios descritos en el contenido de la petición. |
| Extensiones WebDAV | |||
| PROPFIND | RFC 4918 §9.1 | sí / sí | Lee las propiedades de un recurso; la cabecera Depth elige la profundidad del árbol. |
| PROPPATCH | RFC 4918 §9.2 | no / sí | Define o elimina varias propiedades de un recurso en una sola petición. |
| MKCOL | RFC 4918 §9.3 | no / sí | Crea una colección, el recurso de WebDAV similar a una carpeta. |
| COPY | RFC 4918 §9.8 | no / sí | Copia un recurso al URI indicado en la cabecera Destination. |
| MOVE | RFC 4918 §9.9 | no / sí | Mueve un recurso al URI indicado en la cabecera Destination. |
| LOCK | RFC 4918 §9.10 | no / no | Bloquea un recurso en modo escritura y devuelve un testigo de bloqueo. |
| UNLOCK | RFC 4918 §9.11 | no / sí | Libera un bloqueo con el testigo de la cabecera Lock-Token. |
| ACL | RFC 3744 §8.1 | no / sí | Lee o cambia la lista de control de acceso de un recurso. |
| SEARCH | RFC 5323 §2 | sí / sí | Ejecuta una consulta DASL sobre una colección y devuelve los recursos que coinciden. |
| MKCALENDAR | RFC 4791 §5.3.1 | no / sí | Crea una colección de calendario con sus propiedades. |
| BIND | RFC 5842 §4 | no / sí | Añade un recurso existente a una colección como nueva vinculación. |
| UNBIND | RFC 5842 §5 | no / sí | Elimina una vinculación de una colección. |
| REBIND | RFC 5842 §6 | no / sí | Mueve una vinculación de una colección a otra. |
| ORDERPATCH | RFC 3648 §7 | no / sí | Cambia la posición de los miembros de una colección ordenada. |
| MKREDIRECTREF | RFC 4437 §6 | no / sí | Crea un recurso de referencia de redirección que apunta a otro URI. |
| UPDATEREDIRECTREF | RFC 4437 §7 | no / sí | Cambia el URI de destino de un recurso de referencia de redirección. |
| Extensiones de versiones (DeltaV) | |||
| VERSION-CONTROL | RFC 3253 §3.5 | no / sí | Pone un recurso bajo control de versiones. |
| REPORT | RFC 3253 §3.6 | sí / sí | Pide un informe de versiones, de propiedades o DAV sobre un recurso. |
| CHECKOUT | RFC 3253 §8.8 | no / sí | Hace escribible un recurso versionado o crea un recurso de trabajo. |
| CHECKIN | RFC 3253 §9.4 | no / sí | Guarda los cambios como una versión nueva y devuelve el recurso a solo lectura. |
| UNCHECKOUT | RFC 3253 §4.5 | no / sí | Cancela el checkout y descarta los cambios no confirmados. |
| MKWORKSPACE | RFC 3253 §6.3 | no / sí | Crea un espacio de trabajo para el trabajo versionado. |
| UPDATE | RFC 3253 §7.1 | no / sí | Aplica los cambios de una versión a otro recurso. |
| LABEL | RFC 3253 §8.2 | no / sí | Añade o elimina una etiqueta en las versiones. |
| MERGE | RFC 3253 §11.2 | no / sí | Fusiona las diferencias entre dos historiales de versiones. |
| BASELINE-CONTROL | RFC 3253 §12.6 | no / sí | Convierte una colección en una colección controlada por líneas base. |
| MKACTIVITY | RFC 3253 §13.5 | no / sí | Crea una actividad que agrupa cambios de varios recursos. |
| Otros métodos registrados | |||
| QUERY | RFC 10008 §2 | sí / sí | Envía una consulta segura e idempotente con los parámetros en el contenido. |
| PRI | RFC 9113 §3.4 | sí / sí | Solo se envía en el preámbulo de conexión HTTP/2, antes de cualquier trama. |
| Eliminados de HTTP | |||
| LINK | RFC 2068 §19.6.1.2 | no / sí | Definido en la RFC 2068 para crear enlaces entre recursos; las revisiones posteriores de HTTP lo eliminaron. |
| UNLINK | RFC 2068 §19.6.1.3 | no / sí | Definido en la RFC 2068 para eliminar enlaces entre recursos; las revisiones posteriores de HTTP lo eliminaron. |
Esta página recoge todos los métodos del registro de métodos HTTP de la IANA, el registro que mantiene la IETF. Cada fila indica el nombre del método, la especificación que lo define, si es seguro e idempotente y una línea sobre lo que hace.
Las filas vienen con la página: nada se genera en tiempo de ejecución, no hay que introducir datos y no se envía ninguna petición mientras lees. El buscador solo filtra la tabla en tu navegador.
Un método es seguro cuando la especificación lo define como de solo lectura: GET, HEAD, OPTIONS, TRACE, PROPFIND, REPORT, SEARCH, QUERY y PRI están marcados como seguros en el registro. Seguro describe la intención, no los efectos que el servidor decida añadir: una petición GET puede registrarse, contarse o facturarse.
Un método es idempotente cuando repetir la misma petición tiene el mismo efecto que enviarla una vez. PUT, DELETE y casi todos los métodos WebDAV y DeltaV son idempotentes; POST, PATCH, CONNECT y LOCK no lo son, así que un cliente o un proxy no deben repetirlos automáticamente tras un tiempo de espera.
La IANA actualiza el registro cuando se publican métodos nuevos, y esta tabla lo sigue: el nombre, las marcas de seguro e idempotente y la primera especificación de la lista. Cuando el registro añade más especificaciones —MKCOL se amplía en la RFC 5689, PROPFIND y REPORT en la RFC 8144— se muestra la RFC que define el método.
Existen métodos fuera del registro. UPnP SSDP envía M-SEARCH por UDP, la RFC 2774 define métodos de extensión con prefijo M- como M-GET, y muchas API inventan sus propios verbos; un servidor que no reconoce un método responde 405 Method Not Allowed y un proxy puede rechazarlo directamente.
LINK y UNLINK vienen de la RFC 2068, la primera especificación de HTTP/1.1, y se retiraron después: el registro todavía los lista con su referencia de borrador, pero ninguna especificación actual de HTTP los usa.
PRI se envía una vez por conexión, en el preámbulo de HTTP/2, antes de cualquier trama; el registro también incluye la forma de asterisco, que se usa como OPTIONS * para dirigirse al servidor entero y no a un recurso. Es fácil confundirlos al leer un registro de peticiones.