📰 Llega QUERY: el método HTTP que evita fingir con POST

Si has programado una API alguna vez, seguro que te has topado con esto: tienes que hacer una búsqueda con quince filtros, la query string se te queda enorme, y acabas mandándola por POST aunque técnicamente no estés creando ni modificando nada. Todo el mundo lo hace. Y todo el mundo sabe que no es correcto.

Pues bien, ese truco de toda la vida tiene ya sustituto oficial. El 13 de julio de 2026 se publicó el RFC 10008, que estandariza un método nuevo llamado QUERY. Y no es un capricho técnico: es el primer verbo nuevo que se añade a HTTP desde que PATCH llegó en 2010. Dieciséis años sin ampliar la lista. Vamos por partes.

El problema que arrastrábamos desde hace años

GET es perfecto para pedir un recurso: es seguro, es idempotente (puedes repetirlo sin miedo) y los intermediarios (cachés, CDNs, proxies) lo entienden y lo cachean sin preguntarte nada. El problema aparece cuando la búsqueda que quieres hacer no cabe en una URL: filtros anidados, listas largas, consultas tipo JSONPath o SQL. Ahí GET se queda corto, porque los navegadores y servidores tienen límites de longitud de URL, y además metes datos potencialmente sensibles en el historial del navegador y en los logs del servidor.

La solución de siempre era tirar de POST, que sí acepta cuerpo de petición sin límite práctico de tamaño. Pero POST tiene un problema de fondo: HTTP lo define como un método que no es seguro ni idempotente por defecto. Eso significa que un proxy o una CDN no puede asumir que repetir la petición es inofensivo, así que no la cachea ni la reintenta automáticamente si falla la conexión. Estás usando la herramienta equivocada porque no había otra.

Qué es exactamente QUERY

QUERY combina lo mejor de los dos mundos. Acepta cuerpo de petición, igual que POST, así que puedes mandar un filtro complejo sin pelearte con el tamaño de la URL. Pero, a diferencia de POST, se declara explícitamente como seguro e idempotente: el cliente no espera que el servidor cambie de estado por hacer esa petición, y puede repetirla las veces que haga falta (por ejemplo, tras un fallo de conexión) sin riesgo de duplicar nada.

Ese matiz, que suena a detalle técnico menor, es justo lo que permite que los intermediarios vuelvan a hacer su trabajo: cachear la respuesta y reintentar automáticamente si algo se corta a mitad de camino. Con POST no podían, porque no tenían garantía de que fuera inofensivo repetir. Con QUERY, sí.

En la práctica, la petición se parece a esto:

QUERY /productos HTTP/1.1
Host: mitienda.com
Content-Type: application/json

{
  "categoria": "portatiles",
  "precio_max": 900,
  "en_stock": true
}

Nada del otro mundo si has trabajado con POST alguna vez. La diferencia está en la semántica que declara el método, no en la sintaxis de la petición.

Quién lo ha escrito y de dónde viene

El RFC lleva la firma de ingenieros de Cloudflare y de Akamai, con contribuciones de la firma alemana greenbytes, gente que lleva años metida en el grupo de trabajo HTTPbis del IETF. No es un invento de un fin de semana: el borrador llevaba circulando desde 2021, puliéndose petición tras petición hasta llegar a estándar formal este julio.

Que estén detrás dos de las CDNs más grandes del mundo no es casualidad. Son precisamente las empresas que sufren en sus propias tripas el problema de no poder cachear ni reintentar búsquedas complejas mandadas por POST. Si QUERY cuaja, los primeros en beneficiarse van a ser ellos mismos, y de paso todo el que dependa de su infraestructura.

Adopción: la parte que no vas a poder usar mañana

Aquí toca ser realista. Tener un RFC publicado no significa que puedas salir corriendo a usarlo en tu API de producción. El soporte, de momento, es parcial y desigual.

Del lado de los frameworks, algunos ya se han puesto las pilas: Laravel y Go ya soportan el método, y Node.js está incorporando soporte en su módulo HTTP. Es decir, si escribes el backend, hoy mismo puedes empezar a experimentar con QUERY en varios de los stacks más comunes.

El problema está en todo lo que hay entre tu backend y el cliente final: proxies inversos, CDNs, firewalls de aplicación web y navegadores. Todas esas piezas necesitan actualizarse para reconocer QUERY como lo que es (un método seguro e idempotente) y tratarlo en consecuencia. Mientras no lo hagan, un proxy antiguo puede bloquear la petición sin más, sin saber qué hacer con un verbo que no reconoce.

El pronóstico que manejan quienes han escrito el RFC es que esa adopción real, de extremo a extremo, va a llevar años, no meses. La comparación que se usa es con el despliegue de IPv6: un estándar técnicamente superior y ya maduro desde hace más de una década, que sigue conviviendo con IPv4 porque cambiar toda la infraestructura de internet no es cuestión de un fin de semana.

Por qué me importa esto como desarrollador

Llevo años trabajando con APIs, y este tipo de detalles de protocolo son de los que parecen minucia hasta que te toca sufrir el problema que resuelven. Si alguna vez has tenido que explicar en una revisión de código por qué una búsqueda de solo lectura va por POST, sabes exactamente de lo que hablo. La respuesta siempre era la misma: “porque no había otra forma de mandar el cuerpo”.

Ahora la hay. No de forma inmediata ni universal, pero el camino está marcado. Si diseñas APIs nuevas hoy, merece la pena tenerlo en el radar: puedes empezar a exponer QUERY como alternativa a tus endpoints de búsqueda por POST en los stacks que ya lo soportan, sin romper nada de lo que ya funciona, y dejar que los clientes vayan migrando a medida que el ecosistema madure. Si gestionas infraestructura propia y te enfrentas a este tipo de decisiones de arquitectura, es justo el tipo de cosa que reviso con clientes que quieren modernizar sus APIs sin meter la pata con cambios prematuros.

Preguntas frecuentes

¿Qué es el método HTTP QUERY?

Es un nuevo verbo HTTP estandarizado en julio de 2026 mediante el RFC 10008. Permite enviar un cuerpo de petición, como POST, pero se declara seguro e idempotente, como GET, lo que permite a cachés y proxies tratarlo como una operación de solo lectura que se puede cachear y reintentar sin riesgo.

¿En qué se diferencia QUERY de POST?

POST no se considera seguro ni idempotente por defecto, así que los intermediarios no pueden asumir que repetir la petición es inofensivo. QUERY sí lo declara explícitamente, lo que permite cachear la respuesta y reintentar la petición automáticamente tras un fallo de conexión.

¿Puedo usar QUERY ya en mi API?

Depende de tu stack. Laravel y Go ya lo soportan, y Node.js está añadiendo soporte en su módulo HTTP. El problema está en los intermediarios (proxies, CDNs, firewalls, navegadores), que todavía necesitan actualizarse para reconocerlo correctamente.

¿Cuánto va a tardar en adoptarse QUERY de forma generalizada?

Quienes escribieron el RFC lo comparan con el despliegue de IPv6: un estándar maduro que lleva más de una década conviviendo con su predecesor porque actualizar toda la infraestructura de internet lleva años, no meses.

Fuentes

• IETF: The HTTP QUERY Method (borrador previo al RFC 10008)
• The Register: HTTP gets a QUERY method (13 de julio de 2026)
• Vídeo de BettaTech: “¡Por fin! El cambio de HTTP que todos necesitamos”

Compártelo si te ha resultado útil, sobre todo con quien todavía esté mandando búsquedas de solo lectura por POST en su API.

¿Le vas a dar una vuelta a QUERY en tu próxima API, o esperas a que el ecosistema madure un poco más? Cuéntame.

Y… a ver cuánto tarda en llegar a tu proxy favorito.