HTTP QUERY: el futuro inmediato de las consultas en las APIs

Una nueva forma de enviar consultas complejas sin convertir la URL en un rompecabezas ni presentar una búsqueda como si fuera una operación de escritura.

Detalles

¿Qué ocurre cuando una consulta necesita filtros, reglas, listas y paginación, pero no debería modificar absolutamente nada?

Durante años, la respuesta habitual fue elegir entre dos caminos imperfectos. El primero: colocar todos los criterios en la URL de una solicitud GET. El segundo: enviar un cuerpo mediante POST, aunque la intención real fuera únicamente consultar. HTTP QUERY aparece para cubrir precisamente ese espacio: una consulta puede llevar contenido estructurado y, al mismo tiempo, declarar de forma explícita que es segura e idempotente.

No se trata de reemplazar GET. Para búsquedas simples, direcciones compartibles y recursos claramente identificables, GET seguirá siendo una excelente opción. QUERY apunta a otro escenario: filtros avanzados, reportes configurables, exploración de catálogos, analítica, búsquedas empresariales y solicitudes cuyo criterio ya no cabe cómodamente en una URL.

The HTTP QUERY Method

La especificación define una solicitud que pide al recurso procesar el contenido enviado de manera segura e idempotente y responder con el resultado.

Consultar el documento oficial RFC 10008 en RFC Editor →

El problema actual de GET no es GET: es lo que le estamos pidiendo hacer

GET funciona muy bien cuando la consulta es pequeña: un identificador, un término, una página o unos pocos filtros. El problema aparece cuando una interfaz visual permite combinar marcas, categorías, rangos, estados, ordenamientos, campos seleccionados y decenas de condiciones.

En ese punto, la URL puede crecer hasta convertirse en una representación difícil de leer, registrar, copiar y mantener. Además, cada intermediario —navegador, proxy, balanceador, servidor o herramienta de seguridad— puede imponer límites diferentes. El propio RFC 10008 señala que esos límites no siempre se conocen de antemano y que la codificación necesaria para representar estructuras complejas en una URI añade sobrecarga.

También existe una cuestión de exposición. Las URLs suelen aparecer en historiales, favoritos, herramientas de análisis, registros de acceso y paneles de observabilidad. Esto no convierte automáticamente a QUERY en un mecanismo de privacidad —el cuerpo también debe protegerse y administrarse correctamente—, pero permite evitar que todo el criterio de búsqueda quede incorporado a la dirección visible.

¿Por qué no basta con seguir usando POST?

Muchas APIs ya resolvieron las búsquedas complejas con rutas como POST /search. Es una solución pragmática y continuará siendo necesaria durante años. Sin embargo, un componente intermedio que solo observa el método no puede saber si ese POST crea algo, ejecuta un proceso con efectos o realiza una consulta que podría repetirse sin riesgo.

QUERY hace visible esa intención en el protocolo. Una infraestructura puede reconocer que la operación es segura e idempotente; un cliente puede considerar un reintento; y una herramienta puede documentarla como consulta sin depender de convenciones particulares. La propuesta no inventa una nueva forma de escribir filtros: crea una forma más clara de expresar qué significa la solicitud.

En palabras del resumen oficial, QUERY procesa el contenido enviado “in a safe and idempotent manner”. Esa frase breve es el centro de toda la propuesta.

Un demo pequeño porque el ecosistema apenas comienza

Para explorar este futuro inmediato se construyó el proyecto Demo_http_query con PowerBuilder 2025 R2 y una API local ASP.NET Core. Durante la preparación del demo no se identificó una API pública ampliamente documentada que ofreciera un endpoint QUERY adecuado para una demostración reproducible. Por esa razón se creó una API propia, pequeña y controlada, con un catálogo de productos en memoria.

La ventana permite construir una misma consulta y enviarla como GET, POST o QUERY. También utiliza OPTIONS para descubrir los métodos admitidos y el encabezado Accept-Query para anunciar el formato aceptado. La respuesta se presenta como un árbol JSON navegable, de modo que la diferencia entre los métodos se entiende sin ocultar el resultado detrás de una consola.

El demo compara GET, POST y QUERY sobre la misma API local. QUERY envía un cuerpo JSON, mantiene semántica de consulta y devuelve el catálogo en un visor navegable.

La prueba también confirma algo importante: no basta con que el servidor conozca el método. El cliente, el runtime, el proxy y las herramientas del camino deben permitir transmitirlo. PowerBuilder 2025 R2 pudo enviarlo mediante HTTPClient.SendRequest("QUERY", ...), mientras ASP.NET Core lo recibió mediante una ruta asociada explícitamente al método.

Las ventajas más visibles

RFC 10008 también contempla aspectos que hacen a QUERY algo más que “POST con otro nombre”: descubrimiento mediante OPTIONS, formatos anunciados con Accept-Query, respuestas almacenables en caché, solicitudes condicionales y la posibilidad de asignar una URI a una consulta o a su resultado.

Los retos para incorporarlo en APIs actuales

Que exista un estándar no significa que la adopción sea instantánea. Los nuevos métodos HTTP son poco frecuentes porque atraviesan muchas capas que durante años fueron configuradas pensando principalmente en GET, POST, PUT, PATCH y DELETE.

• Gateways y firewalls: algunas listas de métodos permitidos rechazarán QUERY hasta que se actualicen.

• Clientes y SDK: generadores de código y enumeraciones cerradas pueden no reconocer todavía el método.

• CORS: en navegadores, QUERY requiere una solicitud previa de comprobación porque no es un método incluido en la lista segura de CORS.

• Caché y observabilidad: las plataformas deben aprender a considerar el contenido de la consulta al identificar resultados, métricas y trazas.

• Documentación: OpenAPI, portales, pruebas automatizadas y políticas internas necesitan representar la nueva operación con claridad.

• Compatibilidad gradual: durante una transición será razonable mantener GET o POST como alternativa.

Una adopción razonable: empezar por los casos difíciles

El mejor camino no parece ser convertir todos los GET existentes. Una adopción prudente puede comenzar en endpoints donde las limitaciones ya son evidentes: motores de búsqueda empresariales, reportes dinámicos, consultas analíticas, filtros geoespaciales, catálogos extensos y exploradores de eventos.

En esos escenarios, una API puede anunciar QUERY con OPTIONS y Accept-Query, mantener temporalmente un POST de compatibilidad y medir qué intermediarios necesitan ajustes. El cambio puede ser incremental, observable y reversible.

Conclusión: una palabra nueva para una intención que ya existía

Las aplicaciones llevan años enviando consultas complejas. Lo nuevo no es la necesidad, sino la posibilidad de expresarla de forma directa dentro de HTTP. GET seguirá siendo la opción más simple y universal. POST seguirá siendo el gran mecanismo de procesamiento. QUERY propone un espacio propio para consultar con contenido estructurado, sin renunciar a la seguridad e idempotencia esperadas de una lectura.

El futuro inmediato dependerá menos de la elegancia del RFC y más de la velocidad con la que servidores, proxies, SDK, navegadores y plataformas de observabilidad aprendan a reconocerlo. El demo en PowerBuilder demuestra que ya es posible experimentar con ese futuro hoy, en un entorno pequeño, visible y controlado.

Fuentes oficiales

• RFC 10008 — The HTTP QUERY Method

• IANA — HTTP Method Registry

• RFC 9110 — HTTP Semantics

• RFC 9205 — Building Protocols with HTTP