HTTP QUERY ya tiene RFC, pero casi ninguna implementación

HTTP tiene un nuevo método para buscar. El IETF publicó la RFC 10008, «The HTTP QUERY Method», en junio de 2026 como Proposed Standard (estándar propuesto) del grupo de trabajo httpbis. Tres meses después, InfoQ informó en septiembre de 2026 de que ningún proyecto ha anunciado un despliegue en producción completado.

El método lo escribieron Julian Reschke, James M. Snell y Mike Bishop. Existe para resolver un problema que todo desarrollador de APIs ha sorteado al menos una vez.

El hueco entre GET y POST

Una petición de búsqueda quiere dos cosas a la vez, y hasta ahora HTTP obligaba a elegir una.

GET es seguro, es decir, no cambia nada en el servidor. Es idempotente, así que un cliente puede reintentarlo sin consecuencias, y se puede cachear. La pega es que todo lo que se pide tiene que caber en la URL. Los filtros largos chocan con los límites de longitud, acaban en los registros de acceso del servidor, y las estructuras anidadas son incómodas de codificar.

POST lleva un cuerpo de cualquier tamaño y forma. Pero está definido como ni seguro ni idempotente, así que las cachés lo omiten, los clientes no pueden reintentarlo con seguridad, y todo lo que hay en medio debe suponer que cambió algo.

QUERY toma la mitad útil de cada uno. La RFC lo define de modo que «el destino de la petición procese el contenido adjunto de manera segura e idempotente» y responda después con el resultado. Es seguro, idempotente y cacheable, y lleva un cuerpo de petición. La RFC describe el caso para el que sirve como aquel en que «los datos transmitidos son demasiado voluminosos para codificarse en el URI de la petición».

Vienen con él unas cuantas reglas. Content-Type es obligatorio: «Los servidores DEBEN hacer fallar la petición si el campo de petición Content-Type ... falta o es incoherente con el contenido de la petición». Un servidor puede anunciar qué formatos de consulta acepta mediante una cabecera Accept-Query. Las peticiones condicionales funcionan con las cabeceras de validación HTTP estándar.

La caché es la parte que hay que hacer bien

Hacer cacheable un método con cuerpo es el problema difícil que la RFC tiene que resolver. Una caché normalmente usa la URL como clave, y el significado de una petición QUERY vive en su cuerpo.

La respuesta de la RFC 10008 es que las claves de caché deben incorporar el contenido completo de la petición junto con los metadatos relacionados. Una caché que ignorase el cuerpo serviría los resultados de una búsqueda para una búsqueda distinta.

La RFC también permite que un servidor devuelva en su lugar una URL para el resultado. Puede asignar un URI a los resultados y apuntar a él con Content-Location o Location, o usar una redirección 303 cuando el procesamiento ocurre de forma indirecta. Eso da a los clientes un GET sencillo que pueden compartir, guardar en marcadores y cachear con normalidad.

La seguridad corta aquí en ambos sentidos. Sacar una consulta de la URL y ponerla en el cuerpo es una mejora de privacidad, porque la RFC señala que un URI «tiene más probabilidades de quedar registrado» que el contenido de la petición. Pero la vía de escape anterior puede deshacerla. La especificación dice que un URI de resultado «DEBERÍA elegirse de forma que no incluya ninguna parte sensible» de la consulta original. Los navegadores añaden una restricción más: QUERY no es un método de la lista segura (safelisted), así que las peticiones de origen cruzado disparan una comprobación previa (preflight) CORS.

Quién lo ha lanzado de verdad

Aquí es donde el estándar se separa de la práctica. InfoQ presenta el estado del soporte como trabajo en seguimiento, no como trabajo terminado.

Proyecto	Estado, según InfoQ
Crate http de Rust	Soporte fusionado
.NET	Incidencia en seguimiento
Axum	Incidencia en seguimiento
Quarkus	Incidencia en seguimiento
Bruno	Incidencia en seguimiento

Ninguno de ellos tiene una fecha anunciada de despliegue en producción. La valoración de InfoQ es que «la adopción real probablemente se medirá en años», porque un método solo se vuelve utilizable cuando los clientes, servidores, proxies y cachés del camino lo entienden todos. Presenta QUERY como un añadido opcional, no como un sustituto de GET o POST.

Qué significa esto para los desarrolladores

No reescriba sus endpoints de búsqueda. Una petición QUERY que se topa con un intermediario que no conoce el método simplemente falla. Usted no controla cada salto entre su cliente y su servidor.

El movimiento útil hoy es más pequeño: reconocer cuál de sus endpoints es un QUERY disfrazado. Un POST /search que no cambia nada en el servidor es el patrón para el que existe este método. Saberlo no cuesta nada ahora y convierte la migración futura en un cambio de nombre en lugar de un rediseño.

Si mantiene una biblioteca cliente, un framework de servidor, un proxy o una caché, el cálculo es distinto, porque usted es el cuello de botella que describe el calendario de adopción. El requisito de la RFC sobre las claves de caché es la parte con más probabilidades de implementarse mal, y hacerlo mal significa servir los resultados de búsqueda de un usuario a otro.

Una advertencia sobre la promesa de seguridad. Que QUERY sea seguro e idempotente es una promesa que su manejador tiene que cumplir, no algo que el método imponga. Nada impide que un servidor modifique estado dentro de un manejador QUERY. Si lo hace, cada reintento y cada caché del camino se convierten en un fallo difícil de encontrar.