HTTP QUERY: el nuevo método que resuelve el limbo entre GET y POST

Durante más de dos décadas, quienes construyen APIs han convivido con el mismo dilema cada vez que una búsqueda se vuelve demasiado compleja para caber en una URL: usar GET y superar los límites del tamaño de la cadena de consulta, o usar POST y renunciar a la semántica segura y cacheable que ofrece GET. La IETF está formalizando la respuesta a este impasse: el método QUERY, definido en el borrador draft-ietf-httpbis-safe-method-w-body, que ya tiene implementaciones experimentales en navegadores y frameworks de servidor.

El problema que motivó el nuevo método

El GET fue diseñado para recuperar un recurso y lleva dos garantías importantes en la especificación HTTP:

Seguro (safe): no debe causar efectos colaterales en el servidor.
Idempotente: repetir la misma petición varias veces produce el mismo resultado.

Estas garantías son lo que permite que proxies, CDNs y navegadores almacenen en caché respuestas de GET y hagan reintentos automáticos sin miedo a duplicar una acción. El problema es que la especificación HTTP/1.1 no define un cuerpo de petición para GET de manera confiable — varios servidores, proxies y bibliotecas simplemente lo descartan. Esto obliga a quienes necesitan enviar filtros complejos, listas grandes de IDs o estructuras anidadas (el caso clásico de búsqueda avanzada, informes o GraphQL) a recurrir a POST.

El POST, por su parte, no es seguro ni idempotente por definición. Un cliente HTTP, un proxy o el propio navegador no pueden asumir que repetir un POST es inofensivo — por eso nunca se almacena en caché automáticamente y requiere cuidado adicional en los reintentos.

Resultado práctico: equipos de API terminan usando POST /search o POST /graphql para operaciones que son, en esencia, lecturas. Funciona, pero se pierde la caché HTTP estándar, la idempotencia implícita y la claridad semántica de que esa llamada no cambia el estado.

Lo que propone el método QUERY

QUERY es un nuevo método HTTP que combina lo mejor de ambos mundos:

Tiene cuerpo de petición, como el POST, permitiendo enviar cargas estructuradas (JSON, XML, el formato que tenga sentido).
Es seguro e idempotente, como el GET — el servidor se compromete a tratarlo como una lectura, sin efectos colaterales.
Es cacheable bajo las mismas reglas de caché del HTTP, siempre que la respuesta incluya los encabezados apropiados (Cache-Control, ETag etc.), ya que el cuerpo de la petición pasa a formar parte de la clave de caché.

En la práctica, una llamada de búsqueda compleja pasaría a parecerse a esto:

QUERY /productos HTTP/1.1
Host: api.ejemplo.com
Content-Type: application/json
Accept: application/json

{
  "filtros": {
    "categoria": ["electronicos", "informatica"],
    "precioMin": 100,
    "precioMax": 2000
  },
  "ordenarPor": "relevancia",
  "página": 1
}

El servidor responde como respondería a un GET: puede anexar encabezados de caché, puede ser servido por un proxy reverso, y el cliente sabe que puede repetir la llamada sin miedo a duplicar nada.

Por qué esto importa en la práctica

Búsquedas y filtros avanzados. Es el caso de uso más directo: endpoints de búsqueda con múltiples filtros, listas de IDs o texto libre extenso dejan de necesitar elegir entre URLs gigantescas (GET con cadena de consulta de cientos de caracteres) o renunciar a la caché (POST).

APIs tipo GraphQL e informes. Consultas que hoy solo funcionan a través de POST — porque el cuerpo de la consulta no cabe o no es seguro en una URL — pasan a tener un método dedicado que expresa correctamente la intención “esto es una lectura”.

Caché HTTP nativo. Con QUERY, CDNs y proxies pueden, en teoría, almacenar en caché respuestas de búsquedas complejas sin que la aplicación necesite implementar su propia capa de caché para eso — siempre que la infraestructura soporte el método.

Claridad de intención. Logs, herramientas de observabilidad y middlewares de autorización pasan a distinguir “esto es una operación de lectura con carga útil” de “esto es una escritura”, lo que simplifica las reglas de auditoría y políticas de límite de tasa diferenciadas para lectura vs. escritura.

Lo que cambia para quienes construyen APIs

Adoptar QUERY hoy requiere atención a algunos puntos:

El soporte de infraestructura todavía es parcial. Navegadores, proxies, balanceadores de carga y frameworks HTTP necesitan reconocer el método explícitamente. Donde no haya soporte, la llamada debe caer a POST con un encabezado o convención que señale la semántica de lectura (algunos frameworks ya adoptan esto como fallback).
Sigue siendo HTTP "común". QUERY no reemplaza GET ni POST — es un tercer método para el caso específico de lectura con carga estructurada. Las operaciones de escritura continúan en POST, PUT, PATCH y DELETE.
La caché exige disciplina en los encabezados. Como la clave de caché pasa a depender del cuerpo de la petición (y no solo de la URL), es necesario garantizar que Cache-Control, Vary y ETag sean correctos para evitar respuestas cruzadas entre cargas útiles diferentes.
Sigue siendo un borrador en evolución. Al estar en proceso de estandarización en la IETF, los detalles de comportamiento (negociación de contenido, interacción con Content-Length, comportamiento en redirección) pueden cambiar hasta la publicación final como RFC.

Dónde seguir la adopción

Siendo un método nuevo, la recomendación para equipos de ingeniería es tratar QUERY como una evolución a observar antes de depender de él en producción: validar el soporte del runtime del servidor, del proxy reverso y de los clientes HTTP utilizados (navegadores, SDKs, herramientas internas) antes de migrar endpoints críticos. Para búsquedas e informes complejos que hoy sufren con URLs gigantes o POST sin caché, vale ya definir la API pensando en una futura migración a QUERY — manteniendo la carga de búsqueda bien definida y la operación libre de efectos colaterales, exactamente como exige el nuevo método.

desenvolvimento