Durante años, muchas conversaciones sobre tecnología han girado alrededor de la inteligencia artificial.
Sin embargo, Internet también evoluciona a través de cambios mucho menos visibles.
Uno de ellos acaba de producirse dentro del propio protocolo HTTP.
En junio de 2026 se publicó RFC 10008, una especificación que define un nuevo método HTTP llamado QUERY. El documento ha sido publicado como Proposed Standard por el IETF y el método ya figura en el registro oficial de métodos HTTP de IANA.
A primera vista puede parecer una noticia exclusiva para desarrolladores.
En realidad, puede tener consecuencias interesantes para las aplicaciones web, los buscadores internos, los filtros avanzados y, por extensión, para quienes diseñamos experiencias digitales.
Porque detrás de un cambio aparentemente técnico hay una cuestión bastante sencilla:
¿Cómo podemos hacer consultas complejas en Internet sin tener que meter toda la información dentro de una URL?
¿Qué problema intenta resolver QUERY?
HTTP ya dispone de métodos conocidos como GET, POST, PUT o DELETE.
Cada uno tiene unas características y unos usos determinados.
Cuando queremos consultar información, GET suele ser la opción habitual. Por ejemplo:
GET /productos?categoria=portatiles&marca=lenovo&ram=32gb
El problema aparece cuando la consulta empieza a crecer.
Imagina un buscador de una tienda online con decenas de filtros: marca, precio, tamaño, memoria, almacenamiento, procesador, disponibilidad, valoración, características concretas…
Todos esos parámetros pueden terminar formando una URL enorme.
La propia especificación de QUERY señala varios problemas relacionados con este enfoque. Entre ellos están los límites de tamaño de las URI, la necesidad de codificar determinados datos dentro de ellas y el hecho de que las URL tienen más probabilidades de aparecer en registros, historiales o marcadores.
Además, una URL gigantesca tampoco suele ser precisamente agradable de manejar.
Hasta ahora, POST era una de las alternativas
Cuando una consulta necesita muchos datos, una solución habitual consiste en utilizar POST y enviar los parámetros dentro del cuerpo de la petición.
Por ejemplo:
POST /productos
categoria=portatiles
marca=lenovo
ram=32gb
precio_max=1000
...
Esta solución funciona.
Sin embargo, tiene una particularidad importante: POST no está definido específicamente como una operación segura e idempotente para realizar consultas.
Y aquí es donde entra QUERY.
¿Qué es exactamente el método QUERY?
QUERY está pensado para realizar una consulta enviando su contenido dentro del cuerpo de la petición.
Un ejemplo simplificado sería:
QUERY /productos
Content-Type: application/json
{
"categoria": "portatiles",
"marca": "lenovo",
"ram": "32gb",
"precio_max": 1000
}
La diferencia fundamental es que QUERY está diseñado específicamente para realizar consultas seguras e idempotentes.
En términos sencillos, eso significa que repetir una misma petición QUERY no debería modificar el estado del recurso consultado.
Por tanto, una aplicación puede volver a enviar la consulta si se produce un problema de conexión, por ejemplo.
Además, la especificación contempla mecanismos relacionados con caché y permite que el servidor pueda asociar una URI al resultado de una consulta para recuperarlo posteriormente mediante GET.
QUERY no sustituye a GET ni a POST
Este punto es importante.
No estamos ante un nuevo método que vaya a hacer desaparecer los anteriores.
GET seguirá siendo fundamental para recuperar recursos.
POST continuará utilizándose para operaciones que necesitan enviar información al servidor y que no encajan en el modelo de GET.
QUERY ocupa otro espacio.
Podríamos entenderlo como una pieza intermedia entre ambos modelos:
GET → consultar mediante la URI.
POST → enviar contenido al servidor para realizar una operación.
QUERY → realizar una consulta enviando los datos de esa consulta en el cuerpo de la petición, pero con semántica segura e idempotente.
Y precisamente ahí está su interés.
¿Por qué puede ser importante para las búsquedas complejas?
Piensa en cualquier aplicación que necesite realizar búsquedas avanzadas.
Un buscador inmobiliario.
Una tienda online.
Una biblioteca digital.
Una plataforma de estadísticas.
Un sistema de gestión empresarial.
Una aplicación de viajes.
Todas ellas pueden necesitar enviar una cantidad considerable de parámetros para obtener exactamente los resultados que busca el usuario.
Con QUERY, esos datos pueden enviarse como contenido de la petición en lugar de depender exclusivamente de la cadena de consulta de la URL.
Esto no significa que de repente todas las búsquedas vayan a cambiar.
Tampoco significa que las URLs vayan a desaparecer.
Simplemente aparece una herramienta más adecuada para determinados tipos de consultas complejas.
¿Y qué tiene que ver todo esto con el diseño web?
Aquí es donde la noticia empieza a ponerse interesante para quienes trabajamos en diseño web.
Un diseñador puede no escribir una sola línea de código relacionada con HTTP.
Sin embargo, diseña interfaces que dependen de ese código.
Un filtro avanzado.
Un buscador.
Un configurador de productos.
Un catálogo.
Un panel de administración.
Una aplicación web.
En todos esos casos, la experiencia que ve el usuario depende de lo que ocurre detrás de la interfaz.
Por eso, cuando la tecnología elimina una limitación, también puede abrir nuevas posibilidades para diseñar determinadas experiencias.
Más filtros no deberían significar una experiencia peor
Imagina una tienda online con cientos de productos.
El usuario quiere encontrar un portátil concreto.
Selecciona:
- Pantalla de 14 pulgadas.
- 32 GB de RAM.
- SSD de 1 TB.
- Procesador concreto.
- Menos de 1.000 €.
- USB-C.
- Teclado retroiluminado.
- Una determinada marca.
Desde el punto de vista del diseño, queremos que esa experiencia sea sencilla.
El usuario debería poder seleccionar sus preferencias sin preocuparse por lo que ocurre detrás.
Por supuesto, QUERY no convierte automáticamente una mala interfaz en una buena.
Pero una infraestructura capaz de gestionar consultas complejas de una manera más adecuada puede ayudar a construir aplicaciones más sofisticadas.
Y eso sí afecta al diseño.
La tecnología también forma parte de la experiencia de usuario
Esta es una idea que muchas veces olvidamos.
Cuando hablamos de experiencia de usuario pensamos en colores, botones, tipografías, animaciones o navegación.
Pero UX también significa:
que las cosas funcionen.
Un formulario que tarda demasiado.
Un buscador que devuelve resultados incorrectos.
Un filtro que obliga a recargar constantemente la página.
Una aplicación que pierde los parámetros de una búsqueda.
Todo eso forma parte de la experiencia.
Por eso diseño y tecnología no deberían entenderse como dos mundos completamente separados.
La interfaz es lo que ve el usuario.
La tecnología es una parte importante de lo que hace posible esa experiencia.
¿Significa que QUERY va a cambiar Internet mañana?
No.
Y conviene evitar el típico titular tecnológico que convierte una especificación nueva en una revolución inmediata.
RFC 10008 ya existe y el método QUERY está registrado oficialmente. Sin embargo, eso no significa que todos los navegadores, servidores, frameworks y aplicaciones web vayan a adoptarlo de manera inmediata. La especificación define el método y sus reglas; después será necesario que el ecosistema incorpore soporte.
Por tanto, estamos ante algo que merece la pena seguir.
No ante una tecnología que vaya a transformar todas las webs de la noche a la mañana.
Un cambio pequeño que puede tener consecuencias grandes
Este tipo de novedades son especialmente interesantes porque muestran cómo evoluciona Internet desde dentro.
No hace falta presentar una interfaz espectacular.
No hace falta una inteligencia artificial capaz de generar una imagen.
A veces, un nuevo método HTTP puede cambiar las posibilidades de una aplicación.
Y eso termina llegando al usuario.
Primero cambia el protocolo.
Después llegan las implementaciones.
Más tarde aparecen nuevas herramientas.
Finalmente, los diseñadores pueden utilizar esas posibilidades para construir experiencias diferentes.
Es un proceso mucho más lento que una aplicación viral.
Pero también puede ser mucho más importante a largo plazo.
Lo que esto significa para el diseño web
En Lumazaki nos interesa especialmente este tipo de evolución porque el diseño web no termina en Photoshop, Figma o WordPress.
Una interfaz tiene que funcionar dentro de un sistema tecnológico.
Por eso creemos que un buen diseño no consiste únicamente en hacer que una página sea atractiva.
También consiste en entender qué hay detrás.
No hace falta convertirse en desarrollador para comprender HTTP.
Tampoco es necesario conocer todos los detalles de RFC 10008.
Sin embargo, entender las posibilidades y limitaciones de la tecnología ayuda a tomar mejores decisiones de diseño.
Y esa diferencia se nota.
Internet nunca está realmente terminado
Quizá lo más interesante de QUERY sea precisamente eso.
HTTP parece una tecnología completamente consolidada.
Lo utilizamos todos los días.
Nuestros navegadores dependen de él.
Las aplicaciones también.
Sin embargo, sigue evolucionando.
RFC 10008 demuestra que incluso un protocolo tan fundamental puede incorporar nuevas formas de trabajar con las consultas. El método QUERY está diseñado para cubrir un espacio que GET y POST no resuelven de la misma manera.
Para el usuario final, probablemente todo esto pase desapercibido.
Y eso es una buena señal.
Porque cuando la tecnología funciona bien, muchas veces no necesitamos saber que está ahí.
Conclusión
El nuevo método QUERY no va a revolucionar Internet de un día para otro.
Pero sí representa una evolución interesante de HTTP.
Permite realizar consultas complejas enviando los datos dentro del cuerpo de la petición, manteniendo además propiedades como la seguridad y la idempotencia que resultan útiles para repetir solicitudes y gestionar determinados escenarios de caché.
Para los desarrolladores, supone una nueva herramienta.
Para quienes diseñamos productos digitales, puede abrir nuevas posibilidades.
Y para los usuarios, quizá el resultado final sea mucho más sencillo:
buscadores que funcionan mejor, filtros más completos y aplicaciones capaces de gestionar consultas más complejas sin complicar la interfaz.
Internet sigue cambiando.
A veces lo hace con grandes titulares.
Y otras veces lo hace con una palabra nueva dentro de una petición HTTP:
QUERY.
Más información
La especificación oficial está disponible en RFC 10008 – The HTTP QUERY Method, publicada por el RFC Editor en junio de 2026.