Si llevas tiempo trabajando con WordPress, sabes que hay una verdad incómoda: cuando las cosas se ponen serias, la API empieza a sufrir.
Filtros complejos, búsquedas avanzadas, queries con múltiples parámetros… y de repente estás metiendo medio JSON en una URL o usando POST para algo que claramente es un GET.
Ahí es donde entra HTTP QUERY (RFC 10008).
Y sí, tiene más impacto del que parece, sobre todo cuando empiezas a escalar arquitecturas reales en WordPress o WooCommerce.
El problema real en WordPress
WordPress tiene dos mundos:
- REST API (wp-json)
- WP_Query (el motor real de consultas)
Y el puente entre ambos nunca ha sido perfecto.
En teoría, la REST API debería abstraer el acceso a datos. En la práctica, acabas reconstruyendo lógica de WP_Query dentro de endpoints personalizados.
Y eso introduce un problema estructural: duplicación de lógica + pérdida de optimización interna del core.
Si ya has trabajado con crecimiento de proyectos en WooCommerce, este problema se vuelve todavía más evidente:
Escalar WooCommerce sin romper WordPress
Caso típico
Quieres hacer una búsqueda avanzada de posts:
- múltiples taxonomías
- rangos de fechas
- meta_query complejas
- ordenaciones dinámicas
Resultado habitual:
POST /wp-json/custom/v1/search
👉 Funciona.
👉 Pero empieza a generar deuda técnica silenciosa.
El problema no es solo estético: estás usando un método HTTP no diseñado para lectura de datos, lo que afecta a caching, proxies y CDNs.
Este tipo de problemas también aparece cuando haces auditorías de SEO técnico en WordPress:
SEO técnico en WordPress: detección de problemas reales
Qué cambia con QUERY
QUERY /wp-json/custom/v1/search
Content-Type: application/json
- sigue siendo read-only
- es cacheable por diseño
- respeta semántica HTTP correctamente
- evita abuso de POST para lectura
Esto no es solo un cambio sintáctico: es un cambio de arquitectura.
En sistemas grandes, esto significa poder mover lógica al edge (CDNs, workers) sin romper consistencia.
El impacto real (no teórico)
1. Mejora brutal en caching
El principal beneficio es que ahora puedes cachear consultas complejas como si fueran recursos GET reales.
Esto reduce carga en base de datos y mejora tiempos de respuesta en WooCommerce o catálogos grandes.
Optimización de rendimiento en WordPress
2. APIs más limpias y mantenibles
POST /filter-products
Se convierte en:
QUERY /products
Esto no solo mejora legibilidad: reduce fricción entre frontend y backend y hace más fácil evolucionar la API sin romper clientes.
Evolución del ecosistema WordPress
3. Headless WordPress más natural
En arquitecturas headless (Next.js, Nuxt o Astro), el problema no es solo consumir datos, sino hacerlo de forma eficiente sin hacks.
QUERY permite representar consultas complejas sin convertir URLs en monstruos imposibles de mantener.
Arquitectura moderna y UX en sistemas web
El problema: WordPress aún no está preparado
A día de hoy:
- WordPress core no soporta QUERY
- REST API no lo implementa
- la mayoría de plugins no lo contemplan
Eso significa que su adopción requiere capas intermedias.
Cómo empezar (en la práctica)
Opción 1: Middleware (recomendado)
Interceptar QUERY y traducirlo a POST internamente manteniendo semántica HTTP limpia hacia el exterior.
Opción 2: Plugin custom
Extender la REST API para soportar el método QUERY y mapearlo a WP_Query sin romper compatibilidad.
Opción 3: API Gateway
Usar herramientas como Cloudflare Workers o Kong para normalizar peticiones antes de llegar a WordPress.
¿Vale la pena ahora mismo?
Sí, si:
- tienes WooCommerce grande
- usas headless WordPress
- tienes problemas de rendimiento o caching
No urgente, si:
- web corporativa simple
- uso básico de REST API
Conclusión
HTTP QUERY no es una moda ni un cambio superficial.
Es una respuesta a una limitación estructural en cómo WordPress ha gestionado históricamente la lectura de datos vía API.
Durante años hemos normalizado el uso de POST para consultas de lectura complejas.
QUERY propone devolver coherencia semántica a ese problema.
Y aunque hoy todavía no sea estándar en WordPress, su impacto se nota especialmente en proyectos donde el rendimiento, el caching y la escalabilidad empiezan a importar de verdad.