Resumen

  • RFC 9110 define el token de método como fuente principal de la semántica de una solicitud: expresa el propósito del cliente, pero cada recurso decide por separado si reconoce, implementa o permite ese método.
  • Safe limita el cambio que pide el cliente, no todos los efectos secundarios del servidor. Idempotent limita el efecto pretendido de repeticiones idénticas, no obliga a devolver la misma respuesta ni a producir un único registro.
  • Un recibo operativo debe unir método, destino, principal autenticado, autorización, precondición, duda sobre el primer intento, idempotencia de aplicación, actor del reintento, respuesta, estado observado y efectos externos.

El método parece un mando. GET, PUT o DELETE encabezan la solicitud y se leen como acciones. Sin embargo, el protocolo los trata como algo más modesto y más útil: una declaración normalizada de lo que el cliente pretende conseguir. La normalización permite razonar sin conocer el código interno. No convierte al verbo en credencial.

Un servidor puede comprender PUT y negarlo en una colección. Puede admitirlo para el recurso y rechazar al usuario. Puede autorizar al usuario y detectar que su versión es antigua. Puede aplicar el cambio y perder la respuesta. Cualquier diseño que reduzca esa cadena a “era PUT” habrá destruido la evidencia que necesita para explicar el resultado.

La interfaz uniforme hace visible la intención

RFC 9110 dice que el método indica para qué se hizo la solicitud y qué espera el cliente como resultado satisfactorio. GET pide una representación actual. PUT pide crear o reemplazar el estado representado en el destino. DELETE pide retirar la asociación entre el URI y su función actual; no promete borrar toda copia física.

Los métodos normalizados deben conservar su significado al aplicarse a recursos distintos. Así un componente genérico puede diferenciar lectura y modificación, decidir qué respuestas son reutilizables o tratar con cautela una repetición. La semántica puede especializarse mediante cabeceras compatibles, como una condición sobre la versión actual.

La uniformidad termina antes de la admisión. Cada recurso determina si implementa y permite la acción. 501 corresponde a un método no reconocido o no implementado. 405 corresponde a uno conocido pero no soportado por ese destino y debe incluir Allow con los métodos actuales.

Allow no enumera identidades autorizadas. Describe la superficie funcional del recurso. Autenticación pregunta quién actúa. Autorización aplica una política a esa identidad, método y destino. El soporte pregunta si el recurso sabe realizar esa clase de acción. Son respuestas distintas y pueden cambiar por motivos distintos.

La Minimum Initial Specification de Heng Lu ayuda a leer esta frontera. El nivel común contiene la semántica estrictamente necesaria para interoperar. La política de negocio y el derecho del principal siguen en manos de quien ejecuta el recurso. Un registro público coordina palabras; no legisla permisos.

Safe no quiere decir sin consecuencias

Una solicitud es segura cuando su semántica definida es esencialmente de lectura: el cliente no pide ni espera modificar el estado del origen. La propia RFC ofrece los límites. El servidor puede escribir registros; un clic en publicidad puede generar un cargo; una implementación puede ejecutar otras actividades no solicitadas. El cliente no se vuelve responsable de lo que el servidor añadió.

La propiedad existe para que indexadores, verificadores de enlaces y mecanismos de precarga actúen sin solicitar daños. Por eso el dueño de una aplicación debe impedir que un GET a page?do=delete ejecute una eliminación. Poner el verbo peligroso en un parámetro no cambia el método que verá un robot.

La auditoría debe separar efecto solicitado y efecto añadido. Un GET privado sigue necesitando autorización. Puede revelar información, consumir cuota o dejar una huella. Safe no garantiza acceso público ni ausencia material de actividad; asigna la responsabilidad de la intención.

Cuando una empresa presenta facturación o rastreo como “efecto natural” de una lectura, conviene preguntar quién diseñó ese efecto, qué evento lo activa, si puede revertirse y si el principal fue informado. El método no responde por la arquitectura que queda detrás.

Idempotent no clona la respuesta

Una repetición idéntica es idempotente cuando su efecto pretendido en el servidor equivale al de un solo intento. PUT, DELETE y los métodos seguros cumplen esa propiedad en RFC 9110. El servidor puede escribir un registro por intento, conservar varias revisiones o devolver respuestas distintas.

Un DELETE repetido puede encontrar que el destino ya no existe. Un PUT repetido puede llegar al mismo estado y obtener otra fecha o validador. La convergencia del efecto solicitado es lo estable; el sobre de respuesta y los efectos secundarios no tienen por qué serlo.

La aplicación puede incumplir la promesa visible. Si un supuesto PUT suma una cantidad, la repetición multiplica el resultado. Si un DELETE reenvía cada vez una orden de cobro o una notificación irreversible, el recurso local puede converger mientras el mundo externo diverge.

Por eso hacen falta claves de operación y deduplicación en cada frontera, además del método. La propiedad del protocolo no sustituye una transacción distribuida ni una compensación. Solo permite formular la pregunta correcta.

El reintento administra un hecho desconocido

Cuando se corta la conexión antes de que llegue la respuesta, el cliente no sabe si la solicitud fue aplicada. Puede haberse perdido antes del servidor, después del commit o junto con la respuesta. La idempotencia permite repetir porque el segundo intento debería alcanzar el mismo efecto deseado aunque el primero hubiera prosperado.

No autoriza un bucle. RFC 9110 desaconseja reintentar automáticamente métodos no idempotentes salvo que la aplicación sepa que esa operación concreta converge o pueda demostrar que no se aplicó. Un proxy no debe repetirlos automáticamente. El cliente tampoco debería repetir de forma automática un reintento automático que ya falló.

La decisión exige el punto de fallo, el contenido, el destino, las condiciones, una clave de operación, un estado consultable y un presupuesto. POST puede ser recuperable con un identificador estable. PUT puede ser peligroso si cada intento activa una consecuencia externa nueva.

Running-Code Primacy desplaza la atención del rótulo a la conducta verificable: ¿los duplicados convergen?, ¿se puede consultar el commit?, ¿están acotados los efectos? La propiedad adquiere valor al funcionar, no al ser citada.

If-Match protege el estado que el autor vio

Una precondición If-Match exige que el recurso conserve un ETag conocido antes de aplicar la modificación. Si ya cambió, el servidor no ejecuta el método y normalmente responde 412. Es una defensa contra sobrescribir trabajo ajeno con una copia antigua.

El ETag no demuestra identidad ni autorización. Quien conoce el valor no adquiere permiso. Quien tiene permiso no convierte un valor antiguo en actual. La política y la precondición deben evaluarse y registrarse por separado.

Tras una respuesta perdida, el estado y el validador pueden revelar que el cambio ya ocurrió. RFC 9110 permite reconocer el éxito anterior en casos limitados, pero advierte del riesgo cuando varios autores no coordinados producen cambios parecidos. El modelo del recurso decide cuánto se puede inferir.

QUERY convierte una convención privada en semántica pública

RFC 10008, publicada en junio de 2026 por Julian Reschke, James Snell y Mike Bishop, define QUERY. No es obra de Fielding. El método lleva contenido como POST, pero declara una consulta segura e idempotente. IANA registra ambas propiedades como positivas.

Muchas aplicaciones enviaban consultas complejas mediante POST para evitar URI largas o datos expuestos en historiales. El resultado era opaco para un componente genérico: sin conocer el recurso, no podía saber que ese POST solo leía y podía repetirse. QUERY da una señal común, mientras el destino conserva el significado de su contenido y la decisión de soportarlo.

El registro no equivale a adopción. Una pasarela puede no reenviarlo; un servidor puede responder 501; un recurso puede responder 405; un usuario puede carecer de autorización. La fila de IANA es un ledger de vocabulario, no una lista de acceso.

La autoridad de Fielding termina donde empieza la atribución

El perfil del IETF revisado el 31 de agosto de 2026 describe a Roy T. Fielding como Senior Principal Scientist en Adobe, cofundador de The Apache Software Foundation, autor del estilo REST y colaborador en HTTP, URI y URI Templates. Enumera 18 RFC y su labor en el HTTP Directorate. UC Irvine registra sus títulos y aportes al Web y Apache.

Su tesis presenta la interfaz uniforme como una restricción que mejora visibilidad, reutilización, escala y evolución independiente, aunque renuncia a parte de la eficiencia específica de cada aplicación. El vocabulario de métodos encarna ese intercambio: muestra intención común sin centralizar la implementación.

RFC 9110 tiene tres editores: Fielding, Mark Nottingham y Julian Reschke. HTTP es trabajo colectivo y acumulado. Las implementaciones eligen. RFC 10008 pertenece a sus autores. Una firma hace rastreable una contribución, no convierte al firmante en dueño del protocolo.

El recibo completo empieza donde acaba el método

Registrar método, URI y origen. Añadir principal autenticado, alcance de la credencial, soporte del recurso, decisión de autorización y versión de política. Conservar ETag o precondición, hash del contenido y efecto pretendido.

Si hay fallo, registrar el último punto confirmado, la posibilidad de que el primer intento se aplicara, clave de idempotencia, actor, disparador, número y espera del reintento. Cerrar con respuesta, estado releído, consecuencias externas, compensaciones e irreversibilidad.

Así el método conserva una función exacta. Dice qué pretende pedir el cliente. No dice quién tiene derecho, si el estado sigue vigente, si el primer intento comprometió, ni qué ocurrió fuera del recurso. Una intención compartida hace interoperable la solicitud. El permiso requiere otro recibo.

Fuentes