HTTP QUERY: el método que por fin cierra el hueco entre GET y POST

El método HTTP que faltaba entre GET y POST: seguro, idempotente, cacheable, con cuerpo en la petición. De la propuesta a la estandarización del IETF.

Cualquiera que haya construido una API de búsqueda conoce este dilema. Quieres exponer un endpoint para consultas complejas: múltiples filtros, ordenaciones, una expresión GraphQL, quizá una consulta estilo SQL. La primera idea es usar GET, que es el método correcto desde el punto de vista semántico: es seguro, es idempotente, es cacheable. Pero GET no tiene un cuerpo definido, así que toda esa complejidad tiene que terminar en el URI, en forma de query string. Funciona mientras los parámetros sean pocos. Luego llegan los límites de longitud (distintos e impredecibles según el cliente, el proxy y la CDN), la codificación de estructuras anidadas se vuelve ilegible, y los datos sensibles terminan registrados en logs y guardados en marcadores, a la vista, en la URL.

Entonces la mayoría de los desarrolladores se rinde y usa POST. Funciona: el cuerpo puede contener cualquier estructura. Pero POST no es ni seguro ni idempotente: un intermediario no puede asumir que repetir la petición es inofensivo, así que no hay caché automática, no hay reintentos seguros, no hay optimizaciones de CDN. Es exactamente la elección que han hecho GraphQL, gRPC-over-HTTP, SOAP y XML-RPC durante años: usar POST incluso para operaciones de solo lectura, pagando el precio en caché y semántica.

Durante años este fue un compromiso aceptado. El 19 de junio de 2026 dejó de serlo: el IETF publicó el RFC 10008, “The HTTP QUERY Method”, como Proposed Standard. Veamos de dónde viene esta propuesta, cómo funciona en detalle, y qué significa hoy para quien diseña APIs.

El nuevo método HTTP QUERY abre un camino entre las dos sendas recorridas hasta ahora, GET y POST.

De dónde viene la propuesta

La idea de un método HTTP seguro con cuerpo en la petición no es nueva: WebDAV ya lo hacía en 2003 con SEARCH (RFC 5323), y antes aún con PROPFIND y REPORT. El problema de esos métodos es que arrastran todo el bagaje semántico de WebDAV, pensado para un espacio de nombres muy específico (gestión de recursos y propiedades), y no se generalizan bien al resto de la web.

La propuesta de un método genérico, pensado explícitamente para cerrar la brecha entre GET y POST en todo HTTP, circula en la comunidad del HTTP Working Group desde hace varios años: las primeras discusiones públicas se remontan al menos a 2021, cuando el draft inicial (que después se convirtió en draft-ietf-httpbis-safe-method-w-body) empezó a circular entre desarrolladores. Desde ahí pasó por numerosas revisiones, catorce versiones del draft, discusiones en la lista de correo del HTTPbis Working Group y varias rondas de Last Call, hasta llegar, en junio de 2026, a la publicación oficial como RFC.

Los autores, tres nombres con un peso específico nada desdeñable en el ecosistema HTTP, son Julian Reschke (greenbytes, históricamente coeditor de las especificaciones HTTP/1.1), James M. Snell (Cloudflare) y Mike Bishop (Akamai). El documento fue patrocinado por el grupo de trabajo HTTPbis del IETF, con Gorry Fairhurst como Area Director responsable.

Un detalle que los autores aclaran explícitamente en el documento: el nombre elegido es “QUERY” y no uno de los métodos WebDAV existentes (SEARCH, REPORT, PROPFIND) precisamente para evitar la ambigüedad semántica de esos métodos y capturar mejor el vínculo conceptual con el query component de un URI, generalizando el patrón a cualquier tipo de recurso, no solo a WebDAV.

El problema que resuelve de verdad

El nudo central, que el RFC 10008 deja negro sobre blanco en la introducción, es que ninguno de los dos métodos clásicos cubre bien el caso de las consultas de solo lectura pero complejas.

Los límites de GET:

• los límites de longitud del URI no son claros ni uniformes: varían de cliente a cliente, de proxy a proxy, de CDN a CDN, y superarlos produce errores difíciles de diagnosticar;
• algunas estructuras de datos son incómodas o imposibles de codificar correctamente en un URI (anidamiento profundo, binarios, texto libre largo);
• los URI de las peticiones terminan más fácilmente registrados en logs, guardados en el historial del navegador o en marcadores, exponiendo datos que quizá no deberían aparecer en claro en un log.

Los límites de POST:

• no es ni seguro ni idempotente, así que un cliente o un intermediario no pueden repetir automáticamente la petición ante un error de red sin arriesgarse a efectos secundarios;
• no es cacheable por defecto, lo que complica bastante el trabajo de las CDN y los reverse proxy delante de APIs que, de hecho, siempre devuelven datos de solo lectura;
• desde el punto de vista semántico es ambiguo: un cliente no puede deducir solo por el método si un POST crea, modifica, elimina o simplemente lee algo.

QUERY toma el cuerpo de POST y la seguridad/idempotencia de GET, y además sigue siendo cacheable: la combinación que, de hecho, GraphQL y compañía llevan años intentando simular usando POST como workaround.

Cómo funciona en la práctica

Una petición QUERY se parece a una POST, pero con la garantía explícita de que el servidor no alterará el estado del recurso objetivo. El Content-Type es obligatorio, porque define el formato en el que se expresa la consulta: puede ser JSON, un formato aplicativo como application/graphql, un formato de consulta estructurado como application/jsonpath, o incluso texto plano.

Un ejemplo con una consulta GraphQL:

QUERY /api/graphql HTTP/1.1
Content-Type: application/graphql

{ users(role: "admin") { id name email } }

Un ejemplo con un filtro de búsqueda estructurado en JSON:

QUERY /feed HTTP/1.1
Content-Type: application/json

{
   "q": "distributed systems",
   "limit": 10,
   "sort": "-published",
   "filters": ["status:active", "type:post"]
}

Y un ejemplo más cercano a una interrogación estilo SQL, con respuesta en CSV:

QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: example/query
Accept: text/csv

select surname, givenname, email limit 10

Si el servidor no entiende o no acepta el Content-Type enviado, responde con códigos de error precisos: 400 Bad Request si la cabecera falta o es incoherente, 415 Unsupported Media Type si el formato no está soportado, 422 Unprocessable Content si la sintaxis es válida pero la consulta no se puede procesar, 406 Not Acceptable si no puede producir una respuesta en el formato solicitado por el Accept del cliente.

La cabecera Accept-Query

El RFC 10008 introduce también una nueva cabecera de respuesta, Accept-Query, con la que un recurso declara tanto el soporte del método QUERY como los formatos de consulta que acepta, usando la sintaxis de los Structured Field Values (RFC 9651):

HTTP/1.1 200 OK
Allow: GET, QUERY
Accept-Query: application/json, application/graphql

Caché, condiciones y redirects

Aquí está buena parte del valor práctico del método. La clave de caché de una respuesta QUERY incluye, además del URI objetivo, el contenido de la petición y los metadatos relevantes: dos consultas distintas sobre el mismo endpoint producen entradas de caché diferentes, pero consultas idénticas pueden servirse desde la caché sin tocar el backend.

QUERY también soporta peticiones condicionales, igual que GET: un cliente puede enviar If-None-Match con un ETag y recibir 304 Not Modified si el resultado no ha cambiado, o usar If-Modified-Since, If-Match, If-Unmodified-Since e incluso range requests.

Para vincular la respuesta a un recurso concreto y reutilizable, el servidor tiene tres caminos:

1. incluir una cabecera Content-Location que apunte a un recurso descargable con una GET posterior;
2. incluir una cabecera Location para consultas repetibles en el futuro;
3. responder con un redirect 303 See Other hacia un URI accesible vía GET.

Y aquí hay una diferencia interesante respecto al comportamiento clásico de los redirects: QUERY preserva su propio método a través de los redirects 301, 302, 307 y 308 (un cliente que sigue esos redirects repite una QUERY, no la convierte en GET). Solo el 303 convierte explícitamente la petición siguiente en GET, que es precisamente el mecanismo pensado para “materializar” el resultado de una consulta como recurso autónomo.

Un detalle a tener presente para quien trabaja con APIs públicas expuestas al navegador: QUERY no está en la lista CORS-safelisted, así que las peticiones cross-origin requieren un preflight OPTIONS, exactamente como ya ocurre hoy con muchas peticiones POST con Content-Type no simple.

En qué punto está la adopción

Publicar un RFC como Proposed Standard no significa que al día siguiente todo el ecosistema lo soporte. Es el primer escalón de la standards track del IETF: la especificación es estable y está lista para implementarse, pero hace falta tiempo para que navegadores, servidores, proxies, CDN y librerías cliente la adopten de verdad.

En el estado actual, ningún navegador principal implementa QUERY de forma nativa. Del lado del servidor la cosa avanza más rápido: Node.js añadió soporte del método en su módulo http ya durante la fase de draft, y Go, gracias a cómo está diseñado net/http, soporta de hecho cualquier método personalizado (incluido QUERY) mediante http.NewRequest, sin necesidad de modificaciones en la librería estándar. Justo después de la publicación del RFC, comunidades de frameworks como Ruby on Rails abrieron discusiones públicas para evaluar un soporte nativo.

Un caso relevante para quien lee este blog: también DMVCFramework, el framework REST/MVC de referencia para Delphi, tiene ya un estudio en marcha para evaluar y diseñar el soporte del método QUERY. Si quieres seguir de cerca estas decisiones técnicas, comentarlas o proponer casos de uso concretos, el sitio adecuado es el Patreon de DMVCFramework: ahí comparto en preestreno el trabajo sobre estas funcionalidades antes de que se hagan públicas.

El patrón que cabe esperar es el mismo que ya se ha visto con otros métodos y cabeceras HTTP que se han convertido en estándar en los últimos veinte años: primero la adopción del lado del servidor y en las herramientas de desarrollo, luego la consolidación en los frameworks, y finalmente, más lentamente, el soporte nativo de los navegadores y de APIs de JavaScript como fetch(). Mientras tanto, quien quiera experimentar ya puede hacerlo del lado del servidor: HTTP, a nivel de protocolo de transporte, nunca ha impedido métodos personalizados, así que implementar un endpoint que responda a QUERY hoy ya es posible con la mayoría de los stacks del lado del servidor, siempre que se tengan en cuenta clientes, proxies intermedios y CDN que quizá todavía no conozcan el método y puedan comportarse de forma impredecible.

Qué significa para quien diseña APIs

Para quien trabaja hoy en APIs REST o en endpoints estilo GraphQL, QUERY no es una urgencia, pero sí un método a seguir de cerca, porque resuelve un problema real y extendido sin introducir un nuevo formato o protocolo, solo una pieza que le faltaba a HTTP. Algunas consideraciones prácticas:

• No es (todavía) el momento de sustituir el tráfico de producción. Con cero navegadores que lo soporten de forma nativa, cualquier uso real hoy pasa por clientes HTTP personalizados o librerías servidor a servidor, no por un formulario o un fetch() en un navegador genérico.
• Es un candidato natural para endpoints internos o servidor a servidor. Si controlas tanto el cliente como el servidor, por ejemplo en una arquitectura de microservicios, ya hoy puedes obtener semántica correcta y caché en consultas complejas sin esperar al soporte de los navegadores.
• Simplifica el diseño de APIs de búsqueda y de APIs estilo GraphQL. En lugar de forzar POST para operaciones de solo lectura, QUERY ofrece por fin una forma semánticamente correcta de expresar “estoy leyendo, con una consulta compleja, y esta petición es segura de repetir y de cachear”.
• No hace falta reinventar nada del lado de la infraestructura. Al ser simplemente un nuevo método HTTP, toda la infraestructura existente basada en cabeceras estándar (caché, ETag, redirects, content negotiation) sigue funcionando, siempre que los distintos intermediarios del camino lo reconozcan correctamente.
• La conversación entre un cliente Delphi y un servidor DMVCFramework. Un caso muy concreto para quien trabaja con Delphi: una aplicación de escritorio (VCL o FMX), un servicio de Windows u otro servidor, escrito en Delphi o en cualquier otro lenguaje, que necesita consultar un backend DMVCFramework con filtros de búsqueda elaborados (múltiples campos, rangos de fechas, ordenaciones, paginación). Hoy la elección es entre una GET con una query string incómoda de construir y potencialmente demasiado larga, o una POST que renuncia a la caché y a la idempotencia solo para “hacer caber” el filtro en el cuerpo. Con QUERY, ese cliente puede enviar el filtro como cuerpo estructurado (típicamente JSON) al endpoint de DMVCFramework, obteniendo semántica correcta, reintentos seguros en caso de error de red, y la posibilidad real de aprovechar caché y reverse proxies delante del servidor, algo que con POST hoy no es posible.

Puntos clave

• El hueco entre GET y POST ya tiene nombre. QUERY combina el cuerpo de POST con la seguridad y la idempotencia de GET, y además sigue siendo cacheable.
• Es una realidad, ya no solo una propuesta. El RFC 10008, “The HTTP QUERY Method”, fue publicado por el IETF como Proposed Standard el 19 de junio de 2026.
• No nace de la nada. Se inspira conceptualmente en SEARCH de WebDAV (RFC 5323, 2003) pero generaliza el patrón a toda la web con un nombre nuevo y sin el bagaje de WebDAV.
• Tiene una sintaxis precisa. Content-Type obligatorio, nueva cabecera Accept-Query para declarar los formatos soportados, códigos de error dedicados (400, 415, 422, 406).
• Preserva la caché y la seguridad de HTTP. Clave de caché basada en contenido y URI, peticiones condicionales, redirects que preservan el método (excepto el 303).
• La adopción está en sus inicios. Todavía ningún navegador nativo, pero Node.js y Go ya lo soportan del lado del servidor, y frameworks como Ruby on Rails y DMVCFramework (para Delphi) están evaluando su adopción.

Preguntas frecuentes

¿Qué es el método HTTP QUERY?

QUERY es un nuevo método HTTP, estandarizado como RFC 10008, que permite enviar una petición con cuerpo (como POST) pero con semántica segura e idempotente (como GET). El servidor procesa el contenido de la petición y responde con el resultado, sin modificar el estado del recurso objetivo.

¿En qué se diferencia de GET y POST?

GET es seguro e idempotente pero no tiene un cuerpo definido, así que las consultas complejas terminan en el URI con límites de longitud y una codificación incómoda. POST acepta cuerpo pero no es ni seguro ni idempotente, por lo que no es cacheable y no se puede repetir automáticamente con seguridad. QUERY toma el cuerpo de POST y la seguridad/idempotencia de GET, y además sigue siendo cacheable.

¿El método QUERY ha sido aceptado oficialmente?

Sí. El 19 de junio de 2026 el IETF publicó el RFC 10008, “The HTTP QUERY Method”, como Proposed Standard, el primer escalón de la standards track del IETF. Los autores son Julian Reschke, James M. Snell y Mike Bishop, producido por el grupo de trabajo HTTPbis. El método está ahora registrado en el IANA HTTP Method Registry como safe e idempotent.

¿Los navegadores y los frameworks ya soportan QUERY?

El soporte está todavía en sus inicios. Ningún navegador principal lo implementa de forma nativa en el momento de la publicación del RFC. Node.js añadió soporte del lado del servidor en su módulo http, Go ya lo soporta como cualquier método personalizado mediante http.NewRequest, y comunidades como la de Ruby on Rails abrieron discusiones para añadirlo justo después de la publicación del RFC. Se espera una adopción progresiva en los próximos meses/años, no inmediata.

¿Por qué no reutilizar métodos de WebDAV como SEARCH, REPORT o PROPFIND?

Porque arrastran todo el bagaje semántico de WebDAV (RFC 5323, RFC 3253, RFC 4918), pensado para un espacio de nombres muy específico, y no capturan bien el vínculo conceptual con el query component de un URI. Los autores del RFC 10008 eligieron un nombre nuevo, QUERY, precisamente para evitar esa ambigüedad y generalizar el patrón a toda la web.

¿DMVCFramework soportará el método QUERY?

Ya hay un estudio en marcha para evaluar y diseñar el soporte del método QUERY en DMVCFramework, el framework REST/MVC para Delphi. Quien quiera seguir de cerca este trabajo, comentarlo o proponer casos de uso puede unirse al Patreon de DMVCFramework.

Fuentes y para saber más: IETF, RFC 10008, “The HTTP QUERY Method” (junio de 2026); IETF Datatracker, página de seguimiento del documento; http.dev/query; kmcd.dev, “The HTTP Query Method”; Anton Oko, “HTTP QUERY: A New Method For Search Queries” en Medium; Dan Horovits, “HTTP’s New Method for Data APIs: HTTP QUERY” en Medium; debate en Hacker News.