El nuevo método HTTP QUERY
(kreya.app)Explicación del método HTTP QUERY, definido recientemente en la RFC 10008
En las API RESTful existentes, tanto GET como POST tenían limitaciones al manejar búsquedas complejas, y para resolverlo, después de una larga discusión, se estandarizó el método QUERY.
Limitaciones de GET
- Si se envían filtros complejos o consultas relacionales como parámetros en la URL, la URL se vuelve excesivamente larga y puede chocar con los límites de longitud del navegador o del servidor.
- Los caracteres no ASCII o especiales requieren codificación, lo que aumenta el tamaño de la solicitud.
- La forma de representar arreglos o estructuras anidadas no está estandarizada (ej.: roles[]=admin vs roles=admin).
- Como el servidor o el middleware registran los parámetros de la URL en los logs, puede haber problemas al transmitir datos sensibles.
- Enviar un cuerpo de solicitud en GET no está prohibido explícitamente por la especificación, pero como proxies, firewalls y navegadores lo manejan de forma distinta, en la práctica no se puede usar.
Problemas del rodeo con POST
- Se puede enviar un cuerpo de solicitud, pero POST está definido como no idempotente (
non-idempotent), por lo que no es seguro reintentarlo automáticamente si falla. - Los proxies o middlewares no pueden reconocer que se trata de una operación de solo lectura, así que no es posible aplicar optimizaciones como el cacheo automático.
- Desde el punto de vista semántico, usar POST, que está pensado para creación o procesamiento de recursos, para búsquedas no encaja con los principios de diseño RESTful.
Método QUERY
- Un nuevo método HTTP que, como GET, es seguro (
safe) e idempotente (idempotent), pero puede incluir un cuerpo de solicitud. - Se puede almacenar en caché, pero al implementarlo hay que incluir el cuerpo de la solicitud en la clave de caché, por lo que su implementación es más compleja que con GET.
- En resumen, su objetivo principal es "reemplazar POST en solicitudes de solo lectura".
Puntos a tener en cuenta
- El soporte de QUERY en clientes, proxies y servidores todavía es limitado, y podría tomar tiempo hasta que exista un soporte completo.
- Si los parámetros de consulta simples con GET son suficientes, no hace falta cambiar nada.
- Si se necesita compartir o guardar en marcadores la URL de datos filtrados, GET sigue siendo adecuado.
6 comentarios
Eh... ¿no habrán pensado que, dependiendo del proxy/firewall/navegador, el método QUERY podría no llegar a aplicarse todavía durante unos 10 años? ¿O será que lo hicieron pensando a muy largo plazo?
Parece que será lo segundo.
Recuerdo que había un problema con la API de servicio de cierta empresa: aunque recibía POST, si no le pasabas exactamente igual los parámetros en la URL, no funcionaba.
En Corea todavía hay bastantes casos en los que, al ver PUT o DELETE, dicen “¿y esto qué es?”, así que no sé cuánto tardará en adoptarse QUERY.
??? : No hagan REST, mejor unifiquen todo con POST
???: POST es bueno para la seguridad
El documento RFC es https://datatracker.ietf.org/doc/rfc10008/.
GET tiene la desventaja de que la URL se hace más larga, pero también parece tener la ventaja de que puedes compartir la dirección URL tal cual, como cuando quieres compartir el resultado de un filtro de búsqueda específico de ElasticSearch.
Como probablemente hay muchos lugares donde las solicitudes GET se usan implícitamente bajo la premisa de que se escriben en la barra de direcciones del navegador, parece que tomará bastante tiempo para que se establezca, más allá del soporte técnico.