REST y OBTENER ... nuevamente

Question

En general, a la comunidad REST parece no gustarle la información compleja en las solicitudes GET. Me pregunto si hay un buen principio detrás de esto, o solo está reificando las restricciones (longitud arbitraria de la URL) en los diccionarios GET.

Estoy satisfecho con la correspondencia entre las URL y los recursos, pero ¿por qué mis solicitudes GET no pueden tomar datos complejos en el cuerpo de la solicitud, en json o xml (permitido por la especificación HTTP)?

El punto de GET, como yo lo entendía, era que las solicitudes GET indican que no modifican el estado del servidor. Esto parece ortogonal a la complejidad de la solicitud. Sin embargo, muchas personas sugieren que las consultas complejas se creen con un PUT o POST, y luego se mencionan en un GET.

Esto parece estar elevando una convención (de no tener cuerpos en solicitudes GET) al estado de un principio, con desafortunados efectos secundarios: tener que mantener el estado de otro objeto que no merece ser un recurso en propio: esa es la consulta.

Pero tal vez me falta algún otro principio. ¡Sus comentarios son bienvenidos!

Answer 1

El temor es que los intermediarios web existentes perderán su cuerpo GET. Afortunadamente, las nuevas especificaciones de httpbis han reformulado el texto en get bodies y lo han hecho un poco menos aterrador. Personalmente, estoy considerando utilizar get bodies con los cuerpos porque quiero registrar solicitudes inseguras y por el momento no tengo una manera fácil de identificar si un POST es seguro o no. Si tiene control sobre los componentes que se encuentran entre su agente de usuario y el servidor de origen, entonces digo "adelante, use GET con cuerpos".