HTTP QUERY: una mejora para APIs, pero no una migración urgente
Tip sobre el nuevo método HTTP QUERY: cuándo puede ayudar en APIs con filtros complejos y por qué conviene adoptarlo con calma.
El IETF ha publicado el RFC 10008, que estandariza un nuevo método HTTP llamado QUERY. La idea es resolver un problema bastante común en APIs: necesitas pedir datos sin modificar nada, pero los filtros son demasiado complejos para meterlos cómodamente en una URL.
Hasta ahora muchas APIs resolvían esto de dos formas imperfectas. O usaban GET con una query interminable, difícil de leer y con límites prácticos de longitud, o usaban POST /search aunque la operación no crease ni modificase recursos. QUERY intenta cubrir ese hueco: enviar un cuerpo con criterios de búsqueda, pero manteniendo semántica segura e idempotente.
Ejemplo conceptual:
QUERY /api/productos
Content-Type: application/json
{
"categoria": "portatiles",
"precioMaximo": 1200,
"stock": true,
"orden": "relevancia"
}¿Significa esto que mañana deberías cambiar todos tus buscadores internos? No. Una cosa es que exista el estándar y otra que todo tu ecosistema lo soporte bien: navegadores, clientes HTTP, proxies, WAF, cachés, logs, balanceadores, SDKs y documentación interna.
Mi recomendación práctica para una web o negocio con API propia sería esta:
- Mantén
GETpara filtros simples y URLs compartibles. - Mantén
POSTsi hoy tienes una búsqueda compleja que ya funciona y tu infraestructura la entiende. - Empieza a mirar
QUERYen APIs nuevas, internas o controladas, donde puedas probar clientes y servidores de punta a punta. - Revisa reglas de seguridad que permitan solo métodos conocidos. Si aparece
QUERY, no debería colarse sin criterio ni bloquearse sin saber por qué. - Documenta bien la intención: búsqueda compleja, sin efectos secundarios y repetible.
Lo interesante no es correr detrás del método nuevo. Lo interesante es pensar mejor la semántica de tus endpoints. Si una petición solo consulta datos, debería estar diseñada como consulta. Si cambia estado, debería quedar claro. Esa distinción ayuda a cachear, depurar, auditar y evitar sustos.
Para proyectos reales, yo lo trataría como una señal de hacia dónde va el diseño de APIs, no como una obligación inmediata. Si tienes filtros de catálogo, buscadores avanzados, informes o paneles con muchos criterios, merece la pena tenerlo en el radar. Pero antes de adoptarlo, prueba tu stack completo.
Fuentes