{"id":36311,"date":"2026-09-15T15:09:17","date_gmt":"2026-09-15T13:09:17","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=36311"},"modified":"2026-09-15T15:13:04","modified_gmt":"2026-09-15T13:13:04","slug":"http-query-el-metodo-que-faltaba-entre-get-y-post","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/es\/frontend-es\/desarrollo-movil\/http-query-el-metodo-que-faltaba-entre-get-y-post\/","title":{"rendered":"HTTP QUERY: el m\u00e9todo que faltaba entre GET y POST"},"content":{"rendered":"\n

Durante casi treinta a\u00f1os, la Web ha convivido con una paradoja sem\u00e1ntica que cualquiera que desarrolle para el backend conoce bien: \u00bfc\u00f3mo se ejecuta una consulta compleja, voluminosa o que contiene datos sensibles, si el \u00fanico m\u00e9todo “seguro” disponible no permite un cuerpo de solicitud?<\/p>\n\n\n\n

Pensemos en cuando necesitamos enviar una consulta de b\u00fasqueda estructurada con filtros anidados, ordenaciones y paginaciones multidimensionales. O quiz\u00e1s una consulta SQL, una expresi\u00f3n JSONPath o un documento GraphQL.<\/p>\n\n\n\n

El primer pensamiento de quien empieza a programar es: a\u00f1ado un par\u00e1metro “q” a la URI y lo env\u00edo con GET, total, qu\u00e9 puede pasar.<\/p>\n\n\n\n

Luego, con el tiempo, los par\u00e1metros pasan a ser 10, 100 o 1000, y la aplicaci\u00f3n explota. Esto sucede porque el proxy que cruza el firewall, almacena los datos en Redis y realiza el balanceo de carga tiene un l\u00edmite de 2048 caracteres para la URI. O bien ocurre porque el firewall registra la URI en texto plano y la env\u00eda a un SIEM, exponiendo datos sensibles como filtros de b\u00fasqueda o credenciales.<\/p>\n\n\n\n

Meter todo esto en una URI con el m\u00e9todo cl\u00e1sico GET nos expone a l\u00edmites f\u00edsicos de transporte y a graves riesgos de seguridad.<\/p>\n\n\n\n

\u00bfQu\u00e9 hace en su lugar quien busca un m\u00ednimo de seguridad? Usa solo solicitudes POST: todo queda oculto en el cuerpo de la petici\u00f3n y no importa si destruimos la sem\u00e1ntica, impedimos el almacenamiento en cach\u00e9 o desesperamos a nuestro profesor de sistemas, lo importante es mantener los datos a salvo.<\/p>\n\n\n\n

He trabajado en un proyecto cuya base segu\u00eda esta misma l\u00f3gica: rudimentaria, pero eficaz.<\/p>\n\n\n\n

La RFC 10008, publicada por la IETF en junio de 2026 y clasificada como Proposed Standard, resuelve finalmente este dilema introduciendo el m\u00e9todo QUERY. Intentemos comprender si vale la pena o si ha llegado demasiado tarde a nuestras mesas de trabajo. Una cosa es el est\u00e1ndar y otra muy distinta su adopci\u00f3n, para la cual har\u00e1n falta a\u00f1os. Se trata de actualizar lenguajes, frameworks, librer\u00edas, proxies, balanceadores, CDNs, WAFs y navegadores.<\/p>\n\n\n\n

Este nuevo verbo combina la garant\u00eda sem\u00e1ntica de seguridad e idempotencia (t\u00edpicas de GET) con la capacidad estructural de transportar un payload extendido en el cuerpo de la solicitud (t\u00edpica de POST).<\/p>\n\n\n\n

En este art\u00edculo exploraremos la g\u00e9nesis del m\u00e9todo QUERY, c\u00f3mo funciona bajo el cap\u00f3, sus implicaciones en el almacenamiento en cach\u00e9 y la seguridad, y c\u00f3mo podemos implementarlo hoy en nuestros backends (o al menos en el futuro, cuando el ecosistema deje de rechazar la petici\u00f3n con un desolador HTTP\/1.0 405 Method Not Allowed).<\/p>\n\n\n

QUERY transporta la consulta en el cuerpo de la solicitud, superando los l\u00edmites de GET, pero con una sem\u00e1ntica de seguridad que POST no puede garantizar.<\/code><\/span><\/pre>\n\n\n
La g\u00e9nesis de un est\u00e1ndar: AUTH48 y el papel del IETF<\/h2>\n\n\n\n
El m\u00e9todo QUERY no naci\u00f3 de la noche a la ma\u00f1ana. Es el fruto del trabajo del grupo HTTPbis de la IETF, redactado por nombres reconocidos de la ingenier\u00eda de protocolos como Julian Reschke (greenbytes), James M. Snell (Cloudflare) y Mike Bishop (Akamai).<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Un detalle interesante tiene que ver con la fase final de revisi\u00f3n del est\u00e1ndar, conocida como “AUTH48”. Por primera vez, el RFC Production Center (RPC) utiliz\u00f3 un proyecto piloto basado en repositorios de GitHub en lugar de los tradicionales y lentos flujos de correo electr\u00f3nico (https:\/\/github.com\/rfc-editor-drafts\/FinalReview-rfc10008).<\/p>\n\n\n\n
Esto permiti\u00f3 una trazabilidad granular de los cambios de redacci\u00f3n, acelerando el lanzamiento de un est\u00e1ndar que promete cambiar las reglas del juego.<\/p>\n\n\n\n
El problema: los l\u00edmites f\u00edsicos y sem\u00e1nticos de GET y POST<\/h2>\n\n\n\n
Para valorar la importancia de QUERY, debemos examinar de cerca las limitaciones que nos han acompa\u00f1ado durante d\u00e9cadas.<\/p>\n\n\n\n
Los l\u00edmites de GET: entre URIs demasiado largos y registros en texto plano<\/h3>\n\n\n\n
Con GET, la consulta vive por completo en la URI. Aunque la RFC 9110 recomienda que la infraestructura soporte URIs de al menos 8000 octetos, en la pr\u00e1ctica nos topamos con firewalls, balanceadores de carga y CDNs no coordinados que aplican l\u00edmites inferiores y variables. Quien trabaje en el \u00e1mbito enterprise sabe bien que 2048 caracteres es un l\u00edmite habitual, mientras que algunos proxies m\u00e1s antiguos se quedan en 1024.<\/p>\n\n\n\n
Superar estos l\u00edmites genera errores como “414 URI Too Long”, siempre dif\u00edciles de diagnosticar, especialmente cuando el problema solo se manifiesta en entornos de producci\u00f3n con tr\u00e1fico real.<\/p>\n\n\n\n
Adem\u00e1s, hay un problema cr\u00edtico de privacidad: las URIs se registran en texto plano en los logs de los servidores. Una simple b\u00fasqueda mediante grep puede extraer una enorme cantidad de datos sensibles con el m\u00ednimo esfuerzo.<\/p>\n\n\n\n
A\u00fan recuerdo cuando, durante una de mis primeras auditor\u00edas de seguridad de logs para un gran operador nacional de telecomunicaciones, salt\u00e9 de la silla: al analizarlos, me di cuenta de que todos los accesos de una determinada aplicaci\u00f3n se realizaban en GET en lugar de POST. Las contrase\u00f1as de miles de usuarios estaban all\u00ed, escritas en texto plano en los archivos de texto del servidor web.<\/p>\n\n\n\n
Aparte de esto, aunque el fen\u00f3meno est\u00e1 mucho m\u00e1s mitigado en comparaci\u00f3n con el pasado, las cabeceras “Referer” hacia sitios de terceros pueden arrastrar datos que deb\u00edan permanecer segregados en el servidor de origen.<\/p>\n\n\n\n
Por estos motivos, GET carga con un pecado original: no es adecuado para transportar datos sensibles, a pesar de ser el \u00fanico m\u00e9todo seguro e idempotente disponible.<\/p>\n\n\n\n
Por \u00faltimo, almacenar en cach\u00e9 estas peticiones es ineficiente. Cualquier variaci\u00f3n sint\u00e1ctica en el orden de los par\u00e1metros o en la codificaci\u00f3n de caracteres invalida la cach\u00e9, transformando consultas sem\u00e1nticamente id\u00e9nticas en recursos distintos.<\/p>\n\n\n\n
El recurso a POST: la p\u00e9rdida del contrato sem\u00e1ntico<\/h3>\n\n\n\n
Para evitar los l\u00edmites de GET, la pr\u00e1ctica com\u00fan ha sido abusar de POST, desplazando la consulta al body: un enfoque sencillo, pero con consecuencias sem\u00e1nticas importantes.<\/p>\n\n\n\n
De este modo ya no tenemos problemas de espacio en la URI y los logs permanecen limpios (es cierto que se puede habilitar el registro del body, pero no suele estar activo por defecto), pero este mecanismo rompe las garant\u00edas del protocolo. El m\u00e9todo POST no es seguro ni idempotente por definici\u00f3n.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Como consecuencia, los intermediarios implicados en el transporte de una solicitud POST, al no saber si est\u00e1 leyendo datos o modificando una base de datos, evitan reenviar la informaci\u00f3n (como hacen los navegadores) o realizar el almacenamiento en cach\u00e9 (como hacen las CDNs).<\/p>\n\n\n\n
Los precursores WebDAV y por qu\u00e9 evitar SEARCH o REPORT<\/h2>\n\n\n\n
Quienes tengan m\u00e1s experiencia o peinen alguna cana recordar\u00e1n sin duda los intentos realizados con WebDAV y m\u00e9todos como “SEARCH” o “PROPFIND”. Todav\u00eda hay quien piensa que WebDAV es una soluci\u00f3n perfecta, pero quiz\u00e1s deber\u00eda cambiar de opini\u00f3n tras conocer esta especificaci\u00f3n y ver c\u00f3mo ha omitido deliberadamente los m\u00e9todos de WebDAV para crear uno completamente nuevo.<\/p>\n\n\n\n
Se decidi\u00f3, sin embargo, no reciclar esos m\u00e9todos, que nac\u00edan estrechamente vinculados al Content-Type “application\/xml”, y empezar desde cero.<\/p>\n\n\n\n
QUERY nace as\u00ed agn\u00f3stico, no asociado a un formato concreto, de manera que cada desarrollador pueda gestionar su propio “Content-Type” con total autonom\u00eda.<\/p>\n\n\n\n
Por lo tanto, estamos adoptando los aspectos positivos de GET: seguridad, idempotencia y almacenamiento en cach\u00e9, sum\u00e1ndole el cuerpo de solicitud de POST.<\/p>\n\n\n\n
Negociaci\u00f3n de contenido y c\u00f3digos de error<\/h3>\n\n\n\n
Al razonar con el “Content-Type” comienzan a aparecer las primeras limitaciones: si un cliente solicita un formato “application\/xml” y el servidor ofrece un contenido distinto, la petici\u00f3n es rechazada. Lo mismo ocurre si el cliente no indica expl\u00edcitamente este par\u00e1metro.<\/p>\n\n\n\n
El est\u00e1ndar define de manera rigurosa este paso en la secci\u00f3n “2.1 Media Types and Content Negotiation”:<\/p>\n\n\n\n