Las búsquedas complejas en API ya no tienen que fingir ser POST con el nuevo método HTTP QUERY

Las reglas del protocolo HTTP siempre han sido claras, si vas a solicitar datos sin modificar el servidor (una operación segura o idempotente), debes usar el método GET. Pero, ¿qué ocurre cuando los parámetros de tu consulta son demasiado grandes o complejos?

El problema histórico entre GET y POST

El método GET está diseñado para enviar sus parámetros exclusivamente a través de la URL (el Query String). Esto siempre ha presentado importantes limitaciones en el desarrollo web moderno:

1. Límites de longitud: Los navegadores, proxies y servidores suelen limitar las URLs (generalmente a unos 2000 caracteres). Una búsqueda con múltiples filtros anidados simplemente no cabe.
2. Estructuras de datos complejas: Enviar un JSON profundo, consultas de GraphQL o largas listas de identificadores a través de parámetros de URL es poco práctico, difícil de codificar y propenso a errores.
3. Seguridad y privacidad: Las URLs quedan registradas en los logs de los servidores, en monitores de red y en el historial del navegador. Enviar datos sensibles en un GET supone un riesgo de exposición.

Para solucionar este callejón sin salida, la industria adoptó una solución temporal que se volvió un estándar de facto: usar el método POST. Al hacer esto, los desarrolladores pueden enviar un cuerpo (Payload) con un documento JSON gigante que contenga toda la lógica de la búsqueda. Sin embargo, esto tiene un precio, POST fue diseñado para crear o modificar recursos. Semánticamente no es idempotente y, lo que es peor, rompe los mecanismos automáticos de caché, dificultando la optimización de las aplicaciones.

El método HTTP QUERY

Para acabar con esta disonancia, el IETF (Internet Engineering Task Force) ha propuesto el nuevo método HTTP QUERY. Este método nace como una pieza que encaja perfectamente en el rompecabezas del protocolo web, tomando los mejores atributos de sus predecesores.

El método QUERY indica explícitamente al servidor que el cliente está realizando una consulta de solo lectura, pero le permite incluir un Payload en el cuerpo de la petición.

Ventajas principales que transformarán las APIs

El impacto de oficializar QUERY dentro del ecosistema HTTP soluciona los problemas arrastrados durante años:

• Semántica correcta y Caché: Al igual que GET, QUERY es seguro e idempotente. La principal revolución es que sus respuestas pueden ser cacheadas eficazmente utilizando las cabeceras estándar (como Cache-Control), lo que mejorará el rendimiento general sin necesidad de soluciones a medida complejas.
• Sin límites en la carga de datos: Puedes enviar las consultas GraphQL más pesadas, las búsquedas geoespaciales más complejas o filtros JSON masivos dentro del cuerpo de la petición, evadiendo las restricciones de longitud de la URL.
• Privacidad y limpieza: Al viajar en el body, las consultas de los usuarios no se filtran en los registros de acceso convencionales, manteniendo los logs del servidor limpios y seguros.

Conclusión

La introducción de QUERY representa un acto de madurez para el protocolo HTTP. Aunque tomará un tiempo que la adopción llegue a todos los proxies, navegadores, frameworks de desarrollo e infraestructuras de red, el camino está trazado. Las búsquedas complejas pronto podrán dejar de utilizar POST como un parche, permitiendo un desarrollo de APIs más elegante, rápido y fiel a las bases de la arquitectura web.