Explicación del nuevo método HTTP QUERY

Artículo original ↗ Discusión en Hacker News ↗

Qué pretende resolver QUERY

  • Se lo considera una formalización de “GET con un cuerpo”: seguro, idempotente, cacheable, pero puede llevar un cuerpo de la solicitud.
  • Está pensado para reemplazar trucos como GET con cuerpo o POST para consultas (por ejemplo, búsqueda, consultas GraphQL).
  • Quienes lo apoyan dicen que aclara la semántica para los intermediarios: “esto se puede cachear, es de solo lectura y tiene un cuerpo”.

¿Por qué no simplemente arreglar GET?

  • Un sector: simplemente estandarizar GET con cuerpo; QUERY es una redundancia, una hinchazón de “estándares XKCD”.
  • Réplica: muchos proxies, WAFs, CDNs y frameworks existentes eliminan o rechazan los cuerpos en GET, o los tratan como algo sin sentido.
  • Cambiar la semántica de GET crearía un comportamiento indefinido en sistemas heredados; un método nuevo puede fallar limpiamente con 405 y permitir un respaldo a POST.
  • Algunos sostienen que ambas vías requieren de todos modos actualizar la infraestructura; ven QUERY como marketing más que como una necesidad técnica.

Compatibilidad, middleboxes y navegadores

  • Hay preocupación de que middlewares “caja negra” mal mantenidos puedan manejar mal los nuevos verbos o incluso fallar.
  • Otros dicen que los estándares deben evolucionar pese al equipo heredado; la infraestructura rota debe arreglarse.
  • Varios señalan que es poco probable (o al menos no está garantizado) que los navegadores implementen QUERY pronto; eso limita su adopción de cara a la web.
  • El encabezado Accept-Query y OPTIONS/405 se citan como mecanismos para negociar compatibilidad.

Casos de uso propuestos

  • APIs de búsqueda como Elastic/OpenSearch, que actualmente abusan de GET con cuerpo o POST; QUERY encajaría de forma natural.
  • GraphQL: usar QUERY para consultas de solo lectura y POST para mutaciones.
  • Filtrado/búsqueda complejos en aplicaciones web: cuerpos JSON en lugar de cadenas de consulta largas.
  • Búsqueda inversa de imágenes y otras consultas basadas en archivos o binarios.

Caché, semántica y REST

  • QUERY se define como cacheable e idempotente; esto abre el caché de CDN/proxy, a diferencia de POST.
  • Los escépticos señalan claves de caché prácticas: los cuerpos carecen de una forma canónica estándar (orden en JSON, espacios en blanco), lo que complica las cachés compartidas.
  • Algunos argumentan que QUERY mejora la claridad de REST/CRUD al separar el GET simple por URL de consultas más complejas; otros dicen que se pueden modelar las consultas como recursos (POST para crear y luego GET).

Seguridad, WAFs y puntos de dolor prácticos

  • Muchos señalan sistemas del mundo real que rechazan o eliminan cuerpos en GET (WAFs, CloudFront, pasarelas de API estrictas).
  • Se ve QUERY como una forma de evitar estos comportamientos indefinidos y reglas de seguridad que tratan GET con cuerpo como algo sospechoso.
  • Otros advierten que QUERY tampoco será compatible inicialmente con esos sistemas, así que la migración seguirá sin ser trivial.