RFC 10008: El nuevo método HTTP QUERY

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

Propósito y semántica de QUERY

  • Introduce QUERY como “GET con cuerpo”: de solo lectura, seguro e idempotente.
  • El objetivo principal: admitir consultas complejas o grandes (p. ej., GraphQL, filtros enriquecidos, imágenes) sin límites de longitud de URL.
  • Está pensado solo para recuperación de datos; la semántica es similar a GET, pero los parámetros de la solicitud residen en el cuerpo.

Caché, idempotencia y seguridad

  • Como QUERY es seguro e idempotente, los intermediarios y clientes pueden almacenarlo en caché y reintentar automáticamente, a diferencia de POST.
  • Debate sobre las claves de caché:
    • Preocupación: usar todo el cuerpo como clave de caché crea claves sin límite, controladas por el usuario, y añade complejidad (ordenación, normalización, hash).
    • Contrapuntos: esto es opcional; las cachés pueden aplicar hash al cuerpo, o mejor, los servidores pueden responder con una URL corta Location que luego puede almacenarse en caché vía GET.
  • Efectos secundarios como el registro y las cuotas se tratan como “ignorados” a nivel de semántica HTTP, igual que con GET.

GET con cuerpo vs. nuevo método

  • Algunos sostienen que la especificación debería simplemente estandarizar un cuerpo en GET.
  • Otros señalan que muchos proxies/servidores ignoran, eliminan o rechazan cuerpos en GET, y que desde hace tiempo se desaconsejan, así que adaptar semántica sobre ello no es seguro.
  • El nuevo método evita manipulaciones silenciosas: un QUERY no soportado tiende a fallar de forma clara (p. ej., 405) en lugar de descartar datos.

Intermediarios y compatibilidad

  • Preocupación: muchos middleboxes históricamente manejan mal métodos desconocidos o cualquier método con cuerpo que no entienden.
  • Sin amplio soporte de gateways/CDN, POST más encabezados personalizados sigue siendo la opción pragmática para algunos.
  • QUERY también debe lidiar con CORS: actualmente no está en la lista segura, así que los navegadores realizan preflight, aunque sea seguro.

Casos de uso y reacciones de desarrolladores

  • Usos sugeridos: consultas grandes de GraphQL, filtros de búsqueda complejos, patrones de dry-run frente a commit (QUERY y luego POST), consultas tipo base de datos, consultas de IA en streaming con secuencias de eventos.
  • Algunos lo ven como una corrección semántica limpia para los trucos de “POST /search” y como algo que encaja mejor con el modelo de métodos de HTTP.
  • Los escépticos lo ven como excesivo: complejidad añadida, nueva infraestructura y otro matiz más que los desarrolladores deben aprender, para un problema que ya era “suficientemente bueno” con GET/POST.

Formularios HTML, marcadores y UX

  • Interés en method="query" en formularios HTML para evitar avisos de “reenviar datos POST” y mapear mejor a operaciones seguras.
  • Deseo más amplio de permitir que los formularios usen más verbos HTTP (PUT/DELETE/etc.) para alinear las interacciones humanas con la semántica REST.
  • Preocupación por la posibilidad de marcar como favoritos si los parámetros de consulta viven en el cuerpo; se discuten mitigaciones mediante URLs GET generadas por el servidor.

Debates de nomenclatura y concepto

  • A algunos les resulta confuso “QUERY” dado el término existente “query string”.
  • Unos pocos sostienen que los verbos HTTP no deberían codificar semántica de negocio en absoluto, viendo esto como un sobrediseño impulsado por REST; otros responden que HTTP siempre ha vinculado semántica a los métodos.