Los métodos HTTP

El protocolo clasifica sus métodos por dos propiedades que se confunden constantemente y que no significan lo mismo.

• Seguro: el método no modifica el recurso. Es solo lectura, y por eso un intermediario puede repetirlo o precargarlo sin pedir permiso.
• Idempotente: repetir la misma petición varias veces deja el sistema exactamente igual que si se hubiera hecho una sola vez. No dice que la respuesta sea idéntica, dice que el efecto lo es.

La relación entre las dos es de una sola dirección: todo método seguro es necesariamente idempotente, porque si no cambia nada, repetirlo tampoco cambia nada. Al revés no se cumple, y DELETE es el contraejemplo que hay que tener en la cabeza: borrar dos veces el mismo intento deja el sistema igual que borrarlo una vez, así que es idempotente, pero desde luego no es seguro.

La idempotencia es lo que permite que un cliente reintente sin miedo cuando se corta la red. Es también la razón por la que el navegador avisa antes de reenviar un formulario: detrás hay un POST, que no es idempotente.

Cuatro métodos no tocan el recurso, y por tanto los cuatro son seguros e idempotentes.

• GET: recupera el recurso. Es el método con el que funciona la navegación normal.
• HEAD: hace lo mismo que GET pero el servidor devuelve solo las cabeceras, sin cuerpo. Sirve para comprobar si un recurso existe, cuánto ocupa o cuándo cambió sin descargarlo.
• OPTIONS: pregunta qué métodos admite el servidor para ese recurso. La respuesta llega en la cabecera Allow, y es la pieza sobre la que se monta el preflight de CORS.
• TRACE: pide al servidor que devuelva la petición tal y como le ha llegado. Es una herramienta de diagnóstico, útil para ver qué le han añadido los intermediarios por el camino.

TRACE viene desactivado en la mayoría de los servidores porque puede filtrar cabeceras internas, y por eso, aunque el protocolo lo defina, en producción casi nunca responde.

Ninguno de estos es seguro, y solo uno de ellos deja de ser idempotente.

• POST: envía datos a la dirección indicada. No apunta a un recurso concreto sino a quien lo va a procesar, y cada envío puede crear uno nuevo. No es idempotente.
• PUT: coloca el recurso en la dirección indicada. Si no existía lo crea y si existía lo reemplaza entero. Es idempotente: mandar tres veces el mismo contenido deja el mismo resultado.
• PATCH: modifica solo una parte del recurso. No se garantiza idempotente, porque una modificación parcial puede estar expresada de forma acumulativa.
• DELETE: elimina el recurso. Idempotente: tras la primera llamada el recurso ya no está, y las siguientes lo dejan igual de ausente.

La pareja que más se pregunta es PUT frente a POST. La forma rápida de decidir es mirar quién elige la dirección: si la elige el cliente, porque sabe exactamente dónde va el recurso, es PUT; si la decide el servidor al crearlo, es POST, y ahí es donde encaja el código 201 con la cabecera Location.

Cómo se usan estos verbos para diseñar una API REST, con sus recursos y sus direcciones, se estudia en el tema de arquitectura cliente/servidor y servicios web del bloque de Desarrollo. Aquí interesan como piezas del protocolo.

Con CONNECT se cierra la lista. CONNECT no pide un recurso: le pide a un proxy que abra un túnel hasta el servidor de destino y se limite a reenviar bytes en los dos sentidos, que es lo que permite atravesar un proxy con una conexión HTTPS que el proxy no puede ni debe descifrar. No es seguro ni idempotente.

De los nueve métodos, los cuatro seguros son GET, HEAD, OPTIONS y TRACE; los no idempotentes son POST, PATCH y CONNECT. Todo lo demás sale de ahí.

WebDAV es una extensión del protocolo, normalizada en el RFC 4918, que añade métodos nuevos para tratar un espacio de direcciones web como si fuera un sistema de ficheros remoto. Con ella se pueden crear carpetas, mover documentos o bloquearlos mientras alguien los edita, cosas para las que HTTP no tenía verbo. Funcionalmente se acerca a lo que hace FTP, pero sobre HTTP y por tanto con su misma autenticación y su mismo cifrado.

Es la tecnología detrás de la carpeta de red que se monta contra un servidor web y de buena parte de la edición de documentos en línea. Los dos últimos métodos de la tabla se añaden aquí por completitud del estándar.