El RFC 10008 ya está publicado, y tapa un agujero que llevamos veinte años esquivando. QUERY manda su carga útil en el cuerpo de la petición, como POST, pero se declara seguro e idempotente, como GET, así que las cachés y la lógica de reintentos tienen permiso para fiarse de él. Viene con una historia de descubrimiento —un OPTIONS más una cabecera Accept-Query que te dice qué tipos de medio acepta el endpoint— y con Location y Content-Location en la respuesta, para que una caché tenga algo con lo que construir su clave. Es un diseño limpio y pequeño. Mi postura: empieza a soportarlo en tus APIs ya, con POST como plan B, porque la especificación nunca fue la parte difícil. La parte difícil es cada caja que hay entre tu cliente y tu proceso de PHP, y esas cajas solo aprenden métodos nuevos cuando alguien las obliga.

Déjame ser concreto sobre el dolor que QUERY pretende acabar, porque no es teórico. Tienes un endpoint de búsqueda. El objeto de filtros es una estructura anidada con quince facetas, un bounding box y una especificación de orden. Lo metes en el query string y estás a una búsqueda guardada de distancia de un 414, tus logs de acceso archivan en silencio direcciones de correo de clientes para siempre, y tu CDN trata cada reordenación de los mismos parámetros como una clave de caché distinta, así que el hit rate se queda en el quince por ciento. Entonces te pasas a POST. Ahora la URL está limpia y el log está limpio, pero le has dicho a todos los intermediarios del camino que esta petición podría cambiar estado. Varnish no la va a cachear. Tu cliente HTTP no la va a reintentar ante un connection reset, lo que significa que un upstream inestable se convierte en un error visible para el usuario en lugar de en un hipo. No resolviste el problema: lo cambiaste por otro y dejaste de pensar en él.

El contraargumento honesto merece algo más que un encogimiento de hombros, así que aquí va en su versión fuerte. POST funciona. Funciona en todas partes, en cada proxy, en cada WAF corporativo, en cada SDK que tus clientes ya escribieron contra tu API. Añadir un tercer camino de código para que una petición de búsqueda pueda teóricamente cachearse es ruido, y de todos modos la mayoría de los resultados de búsqueda son personalizados, lo que mata la caché compartida antes de que QUERY tenga siquiera una oportunidad. Mientras tanto, los navegadores no te van a echar una mano: un formulario HTML sigue emitiendo solo GET o POST, así que QUERY solo existe para fetch y para tráfico servidor a servidor. Y los métodos desconocidos son el sitio donde la infraestructura va a morir: un ALB con lista de métodos permitidos, un WAF cuyo conjunto de reglas por defecto descarta cualquier cosa fuera de los siete clásicos, un proxy corporativo que responde 501 sin cuerpo. Cada uno de esos es un martes por la tarde muy real que no vas a recuperar.

Aun así me quedo con adoptarlo, por una razón que tiene poco que ver con el hit rate de la caché. QUERY te deja decir lo que quieres decir a nivel de protocolo. Ahora mismo, la diferencia entre «este POST lee datos» y «este POST cobra una tarjeta de crédito» vive en un README, en el nombre de una ruta y en la memoria de quien escribió el cliente. Nada en el formato del cable los distingue, así que cada capa genérica —el middleware de reintentos, los circuit breakers, el replay de peticiones en tu proxy de depuración, la lógica de idempotencia de tu cola de trabajos— tiene que asumir el caso peligroso. La semántica que solo puedes expresar en prosa es semántica que no puedes automatizar. QUERY convierte una convención en un hecho sobre el que la máquina puede actuar, y eso compone mucho después de que el argumento del caché se vuelva aburrido.

Por el lado de PHP, la buena noticia es que a casi toda nuestra pila le da igual cuál sea la cadena del método. PSR-7 y PSR-15 lo tratan como un token opaco, Guzzle enviará lo que le pases, y tu controlador lee php://input en vez de $_POST en cualquiera de los dos casos. La fricción está en los sitios concretos que llevan la lista clásica hardcodeada: HttpFoundation de Symfony tiene conjuntos explícitos de qué métodos cuentan como seguros y cacheables, el router de Laravel valida contra verbos conocidos, y cualquier cosa que reconstruya una petición a partir de las globales necesita saber que ni $_GET ni $_POST se te van a rellenar. Nada de eso es cirugía profunda, pero es el tipo de trabajo que solo se hace si alguien abre el issue. Si mantienes un router, un wrapper de cliente HTTP o un esqueleto de API, esta es una contribución de fin de semana genuinamente buena: diff pequeño, vida útil larga.

El patrón que yo pondría en producción este trimestre es poco glamuroso y aburrido a propósito. Registra el mismo handler para QUERY y para POST en tus endpoints de búsqueda e informes. Responde OPTIONS con honestidad, con los métodos y los tipos de medio de Accept-Query que soportas, para que un cliente pueda sondear una vez y cachear la respuesta. En el lado del cliente, intenta QUERY y, ante un 405 o un 501, cae a POST para ese host y recuerda el resultado: no pagues el viaje de ida y vuelta fallido en cada llamada. Luego revisa tu borde: si nginx reenvía el método a FastCGI sin tocarlo, si la lista de permitidos de tu CDN lo incluye, si la acción por defecto de tu WAF ante métodos desconocidos es bloquear o dejar pasar. Media hora de curl contra staging te dirá más sobre tu calendario real de adopción que cualquier discusión sobre la especificación.

Lo que de verdad no sé es dónde está el punto de inflexión. Nadie despliega soporte de QUERY hasta que los clientes lo envían, y ningún cliente lo envía hasta que los servidores lo despliegan, y nada de eso pasa mientras el CDN del medio responde 501. Alguien tiene que mover ficha primero y perder algo. Así que: si hoy gestionas una API pública, ¿activarías QUERY junto a POST este año, o esperas a que tu proveedor de CDN anuncie soporte en un changelog? Y si ya lo intentaste, ¿qué caja de tu pila fue la primera en romperse?