Resumen / Puntos clave
- Un nuevo método HTTP llamado QUERY ha llegado para solucionar la forma defectuosa en que manejamos las búsquedas complejas.
- Finalmente pone fin al abuso de POST para las API de solo lectura.
El pecado semántico que todos cometimos
Durante décadas, la recuperación de datos a menudo significaba codificar los parámetros de búsqueda directamente en la cadena de consulta URL de una solicitud GET. Este enfoque falló rápidamente con búsquedas complejas que involucraban consultas relacionales o datos profundamente anidados. Las URL se dispararon, alcanzando con frecuencia los límites de longitud del navegador o del servidor, y exponiendo todos los parámetros claramente en los registros del servidor y el historial del navegador.
Para sortear las limitaciones de URL, los desarrolladores adoptaron una solución alternativa: usar solicitudes POST para transportar filtros de búsqueda intrincados dentro del cuerpo de la solicitud. Esto, sin embargo, creó una violación semántica significativa. `POST` está diseñado fundamentalmente para crear nuevos recursos, no para la recuperación segura e idempotente de datos existentes.
El uso indebido de `POST` para búsquedas conllevó consecuencias tangibles. Rompió los mecanismos de almacenamiento en caché, ya que los proxies rara vez almacenan en caché las respuestas `POST` debido a su naturaleza no idempotente. Además, su característica no idempotente impidió que los clientes realizaran reintentos automáticos de forma segura en caso de fallos de red, una capacidad fundamental de las operaciones verdaderamente de solo lectura.
Un intento menos común, pero igualmente problemático, implicó enviar un cuerpo de solicitud con un método `GET`. Si bien la especificación HTTP/1.1 lo permitía ambiguamente, establecía explícitamente que dicho cuerpo no tenía "semántica definida" y "DEBERÍA ser ignorado". Esto convirtió a "GET con un cuerpo" en un mito poco fiable y no estandarizado, que nunca obtuvo un soporte consistente en la infraestructura de la web.
QUERY: La seguridad de GET, el poder de POST
Finalmente, llegó el método HTTP QUERY (RFC 10008), formalmente estandarizado en junio de 2026. Representa el "método faltante para la búsqueda", diseñado específicamente para abordar las soluciones semánticas que los desarrolladores han utilizado durante más de dos décadas. Este nuevo verbo se dirige específicamente a la recuperación de datos complejos y de solo lectura.
QUERY combina elegantemente los mejores atributos de sus predecesores. Al igual que GET, es seguro e idempotente, lo que significa que nunca altera el estado del servidor y las solicitudes idénticas producen consistentemente el mismo resultado. Esta propiedad permite reintentos robustos del cliente en caso de fallos. Fundamentalmente, al igual que POST, acepta un cuerpo de solicitud, proporcionando un amplio espacio para los parámetros de consulta.
Este diseño híbrido resuelve directamente el problema central de la recuperación de datos enriquecidos. Los desarrolladores ahora pueden enviar estructuras de consulta intrincadas y profundamente anidadas, como cargas útiles JSON, dentro del cuerpo de la solicitud. Esto evita alcanzar los límites de longitud de URL del navegador o del servidor y previene la exposición de parámetros sensibles en los registros. Críticamente, elimina la violación semántica de usar POST para operaciones que no cambian de estado, proporcionando finalmente un enfoque estandarizado, almacenable en caché y semánticamente correcto para búsquedas avanzadas de API.
Almacenamiento en caché más inteligente, mejor seguridad
`QUERY` aporta ventajas operativas significativas más allá de la corrección semántica, particularmente en el almacenamiento en caché y la seguridad. Su diseño aborda desafíos de larga data que afectaron a `GET` y `POST` en escenarios complejos de recuperación de datos.
Las respuestas generadas por un método `QUERY` son completamente almacenables en caché, reflejando la eficiencia de `GET`. Críticamente, el cuerpo completo de la solicitud influye directamente en la clave de caché. Este sofisticado mecanismo garantiza que cada cuerpo de consulta único, independientemente de la URI, produzca una entrada de caché distinta, facilitando una recuperación de datos precisa y eficiente.
Un mecanismo de descubrimiento incorporado mejora aún más la utilidad de `QUERY`: el encabezado `Accept-Query`. Los servidores ahora pueden anunciar explícitamente los formatos de consulta específicos que admiten, agilizando la comunicación cliente-servidor y mejorando la detectabilidad de la API. Los clientes obtienen claridad sobre las sintaxis esperadas, reduciendo la fricción de integración.
La seguridad y la privacidad también experimentan mejoras notables. `QUERY` no es un CORS-safelisted method, lo que requiere una solicitud `OPTIONS` de preflight para llamadas de origen cruzado y refuerza la seguridad de las aplicaciones web. Más importante aún, mantiene los parámetros de consulta sensibles fuera de las URL, evitando su exposición en los registros del servidor, los registros de proxy y el historial del navegador, una victoria significativa para la privacidad sobre `GET`.
Este diseño cuidadoso convierte a `QUERY` en una solución robusta para las necesidades modernas de las API. Para especificaciones técnicas más detalladas, consulte RFC 10008: The HTTP QUERY Method, que detalla todas sus capacidades e implicaciones para la arquitectura web.
Enjoying this? Get one like it in your inbox each morning.
one email a day · unsubscribe in two clicks · no third-party tracking
El camino hacia la adopción: una verificación de la realidad
`QUERY` (RFC 10008) ahora está formalmente estandarizado, un paso adelante crítico para la semántica HTTP. A pesar de este logro fundamental, la adopción generalizada en todo el ecosistema web aún se encuentra en sus primeras etapas. Los navegadores, los diversos frameworks web y los proxies de red están implementando progresivamente su soporte para este nuevo método, un proceso que lleva tiempo para un cambio de protocolo fundamental.
El impulso es claramente creciente, con actores clave que ya están integrando `QUERY` en sus plataformas. OpenAPI 3.2 ahora soporta formalmente el método `QUERY`, permitiendo a arquitectos y desarrolladores definir estos potentes nuevos endpoints directamente dentro de sus especificaciones de API. El framework .NET 10 de Microsoft también proporciona un soporte inicial y robusto, lo que indica una fuerte señal para una integración más amplia del framework y fomenta la experimentación temprana.
Las organizaciones deben planificar estratégicamente la eventual omnipresencia de `QUERY`. Para los nuevos endpoints de solo lectura complejos, diseñe con `QUERY` desde el principio, pero implemente alternativas robustas a `POST` o `GET` para la compatibilidad. Finalmente, prepárese para actualizar los firewalls de aplicaciones web (WAFs) y las configuraciones de proxy existentes; estos sistemas deben aprender a interpretar, enrutar y almacenar en caché correctamente las solicitudes `QUERY` para un funcionamiento sin problemas.
Preguntas Frecuentes
¿Qué es el nuevo método HTTP QUERY?
Es un nuevo verbo HTTP estandarizado (RFC 10008) diseñado para búsquedas complejas y recuperación de datos. Combina la seguridad y la capacidad de caché de una solicitud GET con la capacidad de llevar un cuerpo de solicitud como una solicitud POST.
¿Por qué no usar simplemente GET con un cuerpo de solicitud?
El comportamiento de una solicitud GET con un cuerpo no está definido en la especificación HTTP. Esto lleva a un manejo inconsistente y poco fiable por parte de servidores, proxies y cachés, lo que la convierte en una solución poco práctica.
¿Está el método QUERY listo para su uso en producción?
Todavía no para la mayoría de las aplicaciones. Si bien está oficialmente estandarizado, el soporte generalizado en navegadores, frameworks de servidor e infraestructura como proxies y WAFs aún se encuentra en sus primeras etapas.
¿Cómo mejora QUERY el almacenamiento en caché en comparación con el uso de POST para búsquedas?
Las respuestas POST generalmente no son almacenadas en caché por intermediarios como proxies o CDNs. Las respuestas QUERY están explícitamente diseñadas para ser almacenables en caché, utilizando el contenido del cuerpo de la solicitud como parte de la clave de caché, mejorando significativamente el rendimiento.