Resumen

  • QUERY lleva la expresión en el contenido de la petición y está registrada como segura e idempotente. Es una obligación para quien implementa la operación, no una prueba automática de que no tenga efectos de negocio.
  • El contenido y sus metadatos deben formar parte de la clave de caché. Reintentos, redirecciones, validadores, Accept-Query y URI equivalentes asignan poderes diferentes a cliente, caché y origen.

Una aplicación necesita enviar un filtro estructurado, quizá con proyecciones, rangos y condiciones anidadas. GET ofrece una semántica de lectura familiar, pero RFC 9110 no atribuye un significado general al contenido recibido en una petición GET. POST transporta el cuerpo sin dificultad, aunque su condición potencialmente insegura y no idempotente complica la recuperación cuando se corta la conexión.

RFC 10008, publicado en junio de 2026 como Proposed Standard, abre un tercer camino. QUERY pide al recurso de destino que procese una consulta contenida en la petición. El contenido es obligatorio y su tipo de medio define el lenguaje. IANA registra el método como seguro e idempotente y registra Accept-Query como campo HTTP permanente.

No es GET con cuerpo. Tampoco es POST bajo otro nombre. «Seguro» dice que la intención solicitada no modifica el estado de negocio. «Idempotente» dice que varias peticiones idénticas tienen el mismo efecto intencionado que una, no que sus respuestas deban ser idénticas. Una operación que reserva capacidad, consume un derecho o aprueba una transacción incumple la promesa aunque al repetirla devuelva siempre el mismo identificador.

El nombre del método concede permiso para confiar

Las propiedades no son decorativas. Un cliente puede automatizar una lectura segura. Una biblioteca puede reintentar una operación idempotente si desconoce si el servidor llegó a ejecutarla. Un intermediario puede aplicar reglas de almacenamiento cuando entiende el método. El origen que publica QUERY permite que otros actores tomen decisiones basadas en esas propiedades.

Por eso no basta una anotación en el controlador. La evidencia debe unir método, huella exacta del contenido, tipo de medio, contexto de identidad, ejecución, efectos y representación entregada. Ante un reintento, la observación crítica es si la primera llamada llegó al negocio y si la segunda produjo algo que la semántica segura prohibía.

Registrar telemetría incidental no equivale necesariamente a mutar el recurso. Cobrar, gastar un token, avanzar un cursor operativo o emitir una orden sí puede ser parte del efecto solicitado. La revisión debe mirar el resultado para el usuario y terceros, no la etiqueta interna de la función.

La caché no puede olvidar el cuerpo

RFC 10008 exige que la clave de una respuesta QUERY incluya el contenido de la petición y los metadatos relevantes. La misma URI con dos filtros distintos representa dos consultas distintas. Indexar solo por método y URI permite que la respuesta de una pregunta sustituya a la de otra.

El requisito altera la arquitectura. La caché puede necesitar leer el contenido completo antes de calcular la clave. Aparecen límites de tamaño, memoria, latencia y presión de flujo. Sacar la expresión de la URI no hace que desaparezca; la convierte en material de identidad dentro de otra capa.

La normalización puede mejorar la reutilización si la caché comprende el tipo de medio y elimina diferencias verdaderamente irrelevantes. También puede crear equivalencias falsas. Cambiar espacios definidos como insignificantes no es lo mismo que ordenar una lista con significado posicional. no-transform orienta el comportamiento del intermediario, pero no demuestra por sí solo que ninguna etapa haya generado una forma canónica para la clave.

Las pruebas deben buscar tanto falsos negativos como falsos positivos: dos codificaciones del mismo significado y dos significados distintos con sintaxis parecida. Hay que incluir Unicode, números, duplicados, valores predeterminados, compresión, firmas y particiones de autorización. Sin una regla común para todos los analizadores, conservar las diferencias es la opción reversible.

Una respuesta con nombre ya no es efímera

RFC 10008 define el recurso equivalente a partir del destino, el contenido QUERY y sus metadatos. El origen puede asignarle una URI para que una consulta posterior use GET. Esto permite compartir o recuperar un resultado sin volver a transmitir toda la expresión.

Location y Content-Location expresan compromisos diferentes. En una respuesta QUERY correcta, Location puede señalar un recurso equivalente o de consulta recuperable mediante GET. Content-Location vincula la representación devuelta con su URI conforme a la semántica HTTP. Un cliente que trate ambos campos como una URL canónica pierde información sobre qué ha nombrado el servidor.

El acto de nombrar puede exponer. Si la URI generada reproduce el identificador de cuenta o el filtro confidencial, el dato regresa a historiales, registros y referencias. Un identificador opaco reduce ese riesgo, aunque obliga a decidir vigencia, revocación y control de acceso. Una URL persistente puede seguir funcionando cuando el contexto original ya no debería hacerlo.

La sintaxis de RFC 3986 no resuelve esas políticas. El origen que crea el nombre controla su durabilidad y asume el daño si la dirección revela o conserva más de lo debido.

Cada código de redirección gobierna el método

QUERY se conserva con 301, 302, 307 y 308. Las excepciones históricas de POST no se trasladan. El 303 indica de forma expresa que el siguiente paso es GET. Así, unas redirecciones reenvían método y contenido y otra dirige hacia un recurso.

Un gateway que convierta QUERY automáticamente en GET puede perder la expresión o incorporarla a la URI. Convertirla en POST elimina la garantía utilizada para el reintento. El ensayo debe cubrir cada estado, cambios de origen, credenciales y límites de tamaño.

En una QUERY condicional, el validador se evalúa respecto de la representación que seleccionaría GET sobre el recurso equivalente. Negociación de contenido y autorización siguen participando. La huella del cuerpo de consulta no es necesariamente el identificador de la representación resultante.

Una capacidad anunciada tiene ámbito y caducidad

Accept-Query enumera tipos de medio mediante una List de RFC 9651. El anuncio se aplica a recursos del mismo path sin considerar el componente query de la URI; cuando hay varias observaciones, importa la más reciente que siga fresca.

No prueba que cualquier expresión sea válida ni que todas las réplicas coincidan. Hay que registrar qué respuesta, nodo y versión originó el anuncio y hasta cuándo es utilizable.

En navegadores hay una barrera adicional. QUERY no pertenece al conjunto de métodos CORS simples del Fetch Standard, por lo que una petición entre orígenes necesita preflight. Implementar el método en la aplicación no basta si la puerta de enlace o la política de seguridad lo rechaza.

Menos datos en la URI no significa secreto

QUERY puede evitar que una expresión compleja aparezca en enlaces y ciertos logs centrados en la URI. El contenido continúa pasando por cliente, herramientas del navegador, terminación TLS, gateways, cachés, trazas y origen. Puede almacenarse, muestrearse o retransmitirse. Una redirección lo mueve; una URI equivalente mal diseñada lo vuelve visible.

La separación de Lu Heng entre control formal y custodia práctica de los datos evita una conclusión fácil: el origen define la semántica, pero no es el único que posee el contenido en la práctica.

Su modelo de especificación mínima y decisión localizada explica la arquitectura. La capa común define el método, la clave, las redirecciones y el anuncio. Cada origen elige lenguajes y nombres; cada cliente decide emitir o reintentar; cada caché actúa solo si puede conservar la identidad.

La primacía del código en ejecución completa la prueba. El RFC acredita la promesa compartida. Solo las trazas muestran si la operación fue segura, el reintento idempotente, la clave completa y el nombre prudente.