.net - tutorial - verbos http rest

API REST: solicitud GET con cuerpo

Question

Quiero implementar una API REST y necesito un cuerpo en mis solicitudes GET. (Como se discute aquí: HTTP GET con cuerpo de solicitud )

¿Hay clientes http que no pueden enviar un cuerpo con una solicitud GET? Fiddler puede hacerlo, aunque el cuadro de mensaje es rojo.

Answer 1

Como regla general, la idea de un GET en REST es que cualquiera de sus parámetros se envía en la URL. Como indica la respuesta a la pregunta que incluyó, es factible, pero se pierde el sentido de REST, que es tener una interfaz webbish consistente. Si desea pasar datos complejos a su endpoint, es probable que desee utilizar un POST, que sus usuarios esperarán tener un cuerpo. Recomiendo encarecidamente reconsiderar esa implementación.

Pero para su pregunta real, seguro que hay clientes que no pueden enviar un cuerpo en un GET. Sobre todo me imagino que sus clientes serán programáticos, digamos, el urlib2 de python, y aunque puede establecer un cuerpo en GET, no es realmente el uso previsto del módulo, por lo que está forzando al programador a volverse extraño. Lo que es más importante, la idea de la API REST es ser independiente del cliente, por lo que me parece que el diseño de su API se debe volver a trabajar aquí.

Answer 2

Es una mala idea usar body en las solicitudes GET HTTP. Sí, parece ser que el HTTP GET "de jure" puede tener cuerpo, pero "de facto" tendrá problemas:

1. Con marcos / bibliotecas de clientes. Será difícil encontrar apoyo para ello.
2. El servidor puede simplemente ignorar el cuerpo de la solicitud GET. Y de todos modos no es una forma estándar, y podría haber problemas con el servidor o su configuración.
3. Hace que su código, especialmente en el lado del servidor, no sea claro para los demás, porque nadie esperará obtener GET con cuerpo.

¿Estás buscando la manera difícil? Con GET con cuerpo, tendrás tantas trampas. ¿Por qué no usar otro verbo HTTP?

Por ejemplo, use POST (u otros verbos), que:

1. es fácil tener lista la biblioteca del cliente,
2. sin problemas con la configuración del servidor o servidor,
3. está claro para otros

No busques más formas :)