QUERY como nuevo método HTTP (RFC 10008)

Llevo años mintiendo con POST. En realidad todos llevamos haciéndolo desde casi siempre…

Cualquiera que haya montado una API medianamente seria ha terminado usando POST para operaciones que, en realidad, solo querían leer. Un informe complejo en un panel de WordPress. Una búsqueda con diez filtros en WooCommerce. Una query de Elasticsearch tan larga que no cabe ni en un screen.

La alternativa era un GET con una URL de cuatro mil caracteres. Una cadena de &meta_key[]=... que explota el límite de tu servidor web, ensucia los logs de Angie y acaba siendo rechazada por algún WAF conservador. No es elegante. No es honesto. Y, sobre todo, no es HTTP.

Ahora, por fin, existe una tercera opción.

El problema: cuando la pregunta no cabe en la puerta

HTTP nació con una simplicidad brutal. GET para leer, POST para crear, PUT para reemplazar, DELETE para borrar. Pero la web moderna no encaja en esos cuatro cajones.

Imagina un endpoint que devuelve posts filtrados por taxonomía, rango de fechas, metacampos personalizados y múltiples autores. Todo es lectura pura. Pero si intentas codificar eso en la query string de una URI, pronto tienes un monstruo.

Los servidores web no saben qué hacer con una línea de request de seis mil bytes. Los access.log crecen descontroladamente. Y lo peor: si la consulta contiene un email o un token sensible, acaba inmortalizado en el disco de algún servidor intermedio.

La solución chapucera que todos hemos usado ha sido enviar esos datos en el cuerpo de una petición… pero usando POST.

Así que tu servidor recibe un POST que no crea nada, no modifica nada, pero semánticamente le está gritando al mundo: «ojo, esto puede cambiar estado». Los cachés miran para otro lado. Los retries automáticos son peligrosos. Y HTTP, que es un protocolo de palabra, deja de entender qué estás haciendo.

Necesitábamos un método que dijera: «te envío datos para que me los proceses, pero solo para consultar. No toques nada. Y si se cae la conexión, reinténtalo sin miedo».

La solución: GET con cuerpo, sin vergüenza

El RFC 10008 llegó el 15 de junio de 2026. Define el método QUERY. Y, en la práctica, es exactamente eso: un GET que acepta cuerpo sin romper las reglas del juego.

QUERY es «safe»: no modifica el estado del servidor. Es idempotente: puedes repetirlo las veces que quieras sin que pase nada raro. Y, la bomba, es cacheable: una CDN o un proxy puede almacenar su respuesta y servirla a peticiones idénticas sin volver a preguntar al origen.

Hasta ahora, ningún método HTTP combinaba las tres cosas a la vez.

Una petición típica podría lucir así:

QUERY /wp-json/wp/v2/analytics/audience HTTP/1.1
Host: robotstxt.es
Content-Type: application/json
Accept: application/json

{
  "segments": ["newsletter", "rss"],
  "referrers": ["twitter.com", "mastodon.social"],
  "period": {
    "from": "2026-01-01",
    "to": "2026-06-30"
  }
}

El servidor procesa la consulta y devuelve resultados. Sin mentiras. Sin ambigüedad. El Content-Type es obligatorio; si falta, la petición debe fallar con 400. Si el formato no lo soporta, devuelve 415 y puede advertirte con el nuevo header Accept-Query.

El RFC: escrito por gente que maneja internet

Esto no es un borrador de café de un sábado por la mañana. Es un Proposed Standard del IETF, co-firmado por James M. Snell (Cloudflare) y Mike Bishop (Akamai). Gente que sabe lo que cuesta mover peticiones por la Internet a escala real.

El documento es sorprendentemente corto y legible. Veinte minutos. Tiene una elegancia técnica que me recuerda a los RFC viejos: define lo justo, no se mete en formatting wars, y deja la puerta abierta.

La clave está en el concepto de equivalent resource. El servidor puede asignar una URI al resultado de tu consulta y devolverla en un header Location:

HTTP/1.1 200 OK
Location: /cache/queries/a3f7c9e2

A partir de ahí, cualquier cliente puede hacer GET a esa URI. Es un ticket para un resultado ya calculado. Una forma elegante de decir: «esta consulta costó CPU; aquí tienes el recibo».

En la práctica: Angie, cachés y mil sitios

En nuestra infraestructura, esto cambiará el día a día. Como desarrollador, también.

Los logs. Dejar de tener access.log con líneas de seis mil caracteres es un alivio para Netdata y para mis discos. La consulta viaja en el cuerpo, no en la URI.

La caché. Hoy, una petición POST a un endpoint de búsqueda la ignora cualquier proxy. Con QUERY, la respuesta es cacheable por definición. Y aquí el RFC es tajante: la clave de caché debe incorporar el body de la petición y sus metadatos. Los cachés pueden normalizar el JSON (reordenar claves, quitar espacios) para aumentar la tasa de aciertos. Eso significa que mi Angie, o el edge de Cloudflare (co-autor del estándar), podrán cachear búsquedas complejas sin que yo invente un sistema de cache keys personalizado.

WordPress. Los endpoints de WP_Query complejos, los filtros de facetas, las búsquedas contra Elasticsearch… todo encaja aquí. Cuando los frameworks empiecen a soportarlo, register_rest_route() dejará de obligarme a elegir entre una URL inmensa y una mentira con POST.

CORS. Hay un aviso importante: QUERY no está en la lista de métodos CORS-safelisted. En navegadores, disparará un preflight OPTIONS. En nuestra config de Angie, tendremos que añadirlo explícitamente a Access-Control-Allow-Methods cuando se empiece a usarlo para endpoints públicos.

Implicaciones: no todo es inmediato

Sería bonito poder desplegar esto mañana en todos los sitios. Pero la realidad es más lenta.

Go ya permite métodos arbitrarios con http.NewRequest. Rust, con reqwest::Method::from_bytes, también. Pero los frameworks de alto nivel (Express, FastAPI, Django, Laravel, y sí, WordPress) aún no tienen soporte nativo. Los clientes como cURL o Axios funcionarán, pero no siempre con la misma primera clase que GET o POST.

Los proxies legacy, los firewalls empresariales, los middlewares corporativos… todo eso puede rechazar un método que no reconozca. Es el mismo camino que ya recorrió PATCH, estandarizado en 2010 pero que tardó años en ser omnipresente.

Pero la semántica ya está. Y eso permite empezar a diseñar API correctamente desde hoy, aunque el soporte completo llegue en fases.

Conclusión: un poco de honestidad para HTTP

RFC 10008 no reinventa la rueda. No rompe compatibilidad. No añade complejidad innecesaria.

Lo que hace es dejar de mentir. Reconoce que muchas de nuestras operaciones POST eran, en realidad, preguntas. Y que un protocolo que entiende qué estás haciendo es un protocolo que cachea mejor, loguea mejor y falla con más gracia.

Llevamos años forzando cuadrados redondos en POST. Ahora, por fin, HTTP tiene un método que pregunta sin complejos.

¿Dónde habrías usado QUERY este año en tu stack?