- Se propone un nuevo método HTTP: QUERY
- Un método de solicitud seguro e idempotente que puede enviar contenido en la request
- Se puede usar cuando los datos enviados en la request son demasiado grandes para codificarse en la URI
- Cuando los parámetros de consulta superan varios KB, muchas implementaciones imponen límites
- A menudo no es posible conocer ese límite de antemano antes de hacer la solicitud, y además hay que codificarlos, por lo que resulta ineficiente
- Por eso, muchas implementaciones usan POST en lugar de GET para ejecutar consultas
- Sin embargo, si no se tiene conocimiento específico del servidor, no es posible saber si es seguro o idempotente, así que tiene las mismas limitaciones básicas que GET
- El método QUERY ofrece una solución para cerrar la brecha entre el uso de GET y POST
- Al igual que con POST, la entrada para la operación de consulta se envía dentro del contenido de la request y no como parte de la URI de la solicitud
- Pero, a diferencia de POST, este método es explícitamente seguro e idempotente, por lo que puede habilitar funciones como caché y reintentos automáticos
Request
QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: example/query
Accept: text/csv
select surname, givenname, email limit 10
Response
HTTP/1.1 200 OK
Content-Type: text/csv
Content-Location: /contacts/responses/42
Location: /contacts/queries/17
surname, givenname, email
Smith, John, john.smith@example.org
Jones, Sally, sally.jones@example.com
Dubois, Camille, camille.dubois@example.net
7 comentarios
No entiendo por qué habría que agregar esto al protocolo.
¿De verdad hay tantos escenarios donde los parámetros de consulta superan varios KB?
https://www.baeldung.com/cs/http-get-with-body
Parece que la especificación de HTTP deja margen para que el lector la interprete por su cuenta y ha cambiado de forma inconsistente, al punto de que da la impresión de que quieren crear un método nuevo.
GET con cuerpo de solicitud
Algunas bibliotecas cliente ni siquiera tienen una forma de enviar un cuerpo de solicitud al hacer una petición GET, así que parece que podría ser una alternativa.
Desde la perspectiva de quien implementa bibliotecas, ¿no sería más bien una propuesta de cambio al estándar todavía más innecesaria?
Según la especificación del estándar,
GETno puede tener un cuerpo de solicitud, así que sería la biblioteca la que estaría enviando arbitrariamente un cuerpo en la solicitud... En ese caso, ¿no daría igual simplemente implementar un método personalizado del lado de la biblioteca?No diría que la necesidad no exista en absoluto, pero me parece menos convincente en comparación con
PUT,PATCHyDELETE, que surgieron al pasar de HTTP 1.0 a 1.1.https://www.rfc-editor.org/rfc/rfc9110.html#name-method-definitions
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET
https://stackoverflow.com/questions/978061/http-get-with-request-body
https://elastic.co/guide/en/…
La especificación estándar no define nada sobre el body en el método GET; nunca dice que no se pueda incluir.
Como hay casos en los que los frameworks de servidor no procesan el body en el método GET, en MDN recomiendan no incluir un body en el método GET.
Elasticsearch sí soporta body en el método GET
Me parece que hace falta pensar un poco más si la especificación debe cambiar por la implementación de una librería.