13 puntos por xguru 2024-09-18 | 7 comentarios | Compartir por WhatsApp
  • 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

 
regentag 2024-09-19

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?

 
savvykang 2024-09-19

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.

 
nemorize 2024-09-18

GET con cuerpo de solicitud

 
beoks 2024-09-19

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.

 
nemorize 2024-09-20

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, GET no 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, PATCH y DELETE, que surgieron al pasar de HTTP 1.0 a 1.1.

 
babadudu 2024-09-23

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/…

  1. La especificación estándar no define nada sobre el body en el método GET; nunca dice que no se pueda incluir.

  2. 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.

  3. Elasticsearch sí soporta body en el método GET

 
vwjdalsgkv 2024-09-20

Me parece que hace falta pensar un poco más si la especificación debe cambiar por la implementación de una librería.