La IETF publica el RFC 10008: QUERY, el primer método HTTP nuevo desde PATCH
El nuevo verbo permite enviar un cuerpo en una petición de lectura sin renunciar a las garantías de seguridad, idempotencia y caché que da GET.
La IETF ha publicado el RFC 10008, que añade un método nuevo a HTTP: QUERY. Es el primer verbo estándar que se incorpora al protocolo desde que PATCH se estandarizó en 2010, y llega para resolver una discusión que llevaba años abierta. Lo firman Julian Reschke, James Snell y Mike Bishop, sobre una conversación que Asbjørn Ulsberg reabrió en el HTTP Workshop de 2019.
El problema que ataca es conocido por cualquiera que haya diseñado una API de búsqueda. GET es seguro e idempotente, pero sus filtros viajan en la URL: ahí chocan con los límites de longitud, acaban en los logs de acceso y no saben expresar estructuras anidadas. POST sí admite un cuerpo rico, pero no es seguro ni idempotente, así que las cachés lo ignoran, los clientes no pueden reintentarlo a ciegas y los intermediarios tienen que asumir que cambia estado. QUERY es la tercera opción: lleva cuerpo como POST y conserva la semántica de lectura.
En la práctica, una consulta que hoy hay que apretujar en la barra de direcciones pasa al cuerpo, donde el tamaño deja de importar. Las respuestas siguen siendo cacheables siempre que la clave de caché incorpore el contenido de la petición, y los servidores pueden anunciar que lo soportan mediante el nuevo campo de cabecera Accept-Query.
Por qué un método y no un cuerpo opcional en GET
Buena parte del debate público ha girado alrededor de la misma pregunta: si ya se puede colar un cuerpo en un GET, para qué un verbo aparte. El argumento que se repite en los hilos de Hacker News y r/webdev es el diagnóstico de errores. Un GET con cuerpo funciona hasta que deja de funcionar, y entonces hay que averiguar qué proxy, equilibrador o caché del camino se lo comió sin decir nada. Con un método explícito, el servidor que no lo soporta responde que no lo soporta y el problema se localiza en un segundo.
El texto también recuerda los apaños que se hacen hoy. Cloudflare cachea POST creando internamente un GET falso que le sirve de clave. GraphQL y Elasticsearch llevan años tunelando lecturas complejas por POST. La especificación se presenta como una adición opcional junto a GET y POST, no como sustituto de ninguno de los dos.
El soporte de herramientas empieza a moverse. La implementación ya se ha fusionado en el crate http de Rust y hay seguimiento abierto en .NET, Axum, Quarkus y Bruno.
La adopción real se medirá en años, igual que pasó con PATCH. Cada método nuevo tiene que ser entendido por clientes, servidores, proxies y cachés antes de ser fiable, y ese camino es lento por definición. Para quien mantiene APIs, la consecuencia práctica es que a partir de ahora existe una vía estándar para lecturas con filtros grandes sin recurrir a POST ni a trucos de caché.
