java - httpservletrequest - OBTENER la carga útil de solicitud HTTP

java get request body json

Question

Estoy diseñando una API y me pregunto si está bien enviar una carga útil JSON en una solicitud GET.

En esta otra pregunta Payloads de HTTP Request Methods , podemos encontrarlo de acuerdo con este enlace :

• CABEZA - Sin semántica definida del cuerpo.
• GET - Sin semántica definida del cuerpo.
• PUT - Cuerpo compatible.
• POST - Cuerpo compatible.
• ELIMINAR - Sin semántica definida del cuerpo.
• TRACE - Cuerpo no compatible.
• OPCIONES - Cuerpo compatible pero no semántica (tal vez en el futuro).

¿Esto significa que no debería enviar una solicitud GET con una carga útil? ¿Hay riesgos de hacerlo?

• ¿Te gusta tener algunas bibliotecas de clientes HTTP incapaces de enviar esa carga útil?
• ¿O mi código API de Java no es portátil en ciertos servidores de aplicaciones?
• ¿Algo más?

Descubrí que ElasticSearch usaba esa carga en una solicitud GET:

$ curl -XGET ''http://localhost:9200/twitter/tweet/_search?routing=kimchy'' -d ''{
"query": {
"filtered" : {
"query" : {
"query_string" : {
"query" : "some query string here"
}
},
"filter" : {
"term" : { "user" : "kimchy" }
}
}
}
}
''

Entonces, si esta popular biblioteca lo hace y nadie se queja, entonces ¿puedo hacer lo mismo?

Por cierto, me gustaría saber si esto está bien para mezclar los parámetros de queryString y la carga JSON? Exactamente como esta consulta de ElasticSearch sí. Si es así, ¿existen reglas para que sepamos qué argumentos deberían ser parámetros queryString o parámetros de carga?

Aquí podemos leer: HTTP GET con cuerpo de solicitud

Comentario de Roy Fielding sobre incluir un cuerpo con una solicitud GET.

Sí. En otras palabras, cualquier mensaje de solicitud HTTP puede contener un cuerpo de mensaje y, por lo tanto, debe analizar los mensajes teniendo esto en cuenta. Sin embargo, la semántica del servidor para GET está restringida, de modo que un cuerpo, si lo hay, no tiene ningún significado semántico para la solicitud. Los requisitos para el análisis son independientes de los requisitos de la semántica de los métodos.

Entonces, sí, puedes enviar un cuerpo con GET, y no, nunca es útil hacerlo.

Esto es parte del diseño estratificado de HTTP / 1.1 que se volverá a aclarar una vez que la especificación esté particionada (trabajo en progreso).

.... Roy

Entonces, realmente no entiendo por qué nunca es útil, porque tiene sentido, en mi opinión, enviar consultas complejas al servidor que no encajarían bien en queryParam o matrixParam. Creo que los diseñadores de la API ElasticSearch piensan lo mismo ...

Estoy planeando diseñar una API que se pueda llamar así:

curl -XGET ''http://localhost:9000/documents/inbox?pageIndex=0&pageSize=10&sort=title''
curl -XGET ''http://localhost:9000/documents/trash?pageIndex=0&pageSize=10&sort=title''
curl -XGET ''http://localhost:9000/documents/search?pageIndex=0&pageSize=10&sort=title'' -d ''{
"someSearchFilter1":"filterValue1",
"someSearchFilter2":"filterValue2",
"someSearchFilterList": ["filterValue3","xxx"]
... a lot more ...
}
''

¿Te parece bien? En base a las consideraciones anteriores.

Answer 1

Hacer que la respuesta GET varíe según el cuerpo de la solicitud interrumpirá el almacenamiento en caché. No vayas allí.

Answer 2

Google App Engine, un marco web popular, utiliza una biblioteca especial de recuperación de URL, que no admite la realización de solicitudes HTTP GET con una carga útil . En consecuencia, si desea que su API llegue a los usuarios de Google App Engine, no recomendaría que se requiera este comportamiento.

He abierto un problema con respecto a esto con google.

Answer 3

Solo porque puedas hacer algo, no significa que debas hacerlo . Lo siento si esto suena exasperantemente tautológico, pero la cuestión de los estándares es que son estándar , y HTTP es uno de los estándares más establecidos que existen. No es perfecto, y hay muchas cosas que a mucha gente le gustaría cambiar al respecto, pero el hecho de que casi todos sigan usando parámetros de URL para casos de uso como este es suficiente indicación de que no existen cualquier alternativa confiable en este momento.

Las respuestas de speedplane y Julian Reschke dan dos ejemplos concretos de cosas que se romperán si dependes de las solicitudes GET con un cuerpo / carga útil. Si lo desea, puede escribir su aplicación de manera diferente para todos los demás, pero la web es un área en la que los estándares quizás deberían tomarse con más seriedad de lo normal. Sé que es tentador ser un pionero, pero con todo respeto, considere cuántos sitios web existen y cuántos programadores web los están construyendo y manteniendo. Si hubiera una forma definitivamente mejor, lo más probable es que ahora la utilices ampliamente en producción.

Los estándares cambian / se adoptan lentamente porque muchas personas tienen que ponerse de acuerdo para que funcionen. Tiene razón al decir que hay aplicaciones que infringen las reglas, pero notará que han causado dolores de cabeza a las personas, y en algunos casos se requieren medidas de solución / redundancia, como lo menciona Aetherus en su comentario sobre otra respuesta. Tiendo a tomar el camino de la menor resistencia en temas como este. Si realmente quieres hacerlo, estoy seguro de que puedes hacerlo funcionar, sin embargo.

Answer 4

Ver también: HTTP GET con cuerpo de solicitud - para más detalles sobre esto.

La esencia es: Sí, puedes, pero probablemente no deberías por varias razones, incluyendo:

• Probablemente esté ignorando las recomendaciones de especificaciones HTTP (es probable que desee POST)
• Puede presentar problemas de almacenamiento en caché
• Esto no es intuitivo en lo que respecta a las API REST