¿Es RESTful crear objetos complejos en un único POST?

Question

Tengo un formulario donde los usuarios crean registros de personas. Cada persona puede tener varios atributos: altura, peso, etc. Pero también pueden tener listas de datos asociados, como intereses, películas favoritas, etc.

Tengo un formulario único donde se recopilan todos estos datos. Para mí, parece que debería PUBLICAR todos estos datos en una sola solicitud. ¿Pero es eso RESTful? Mi lectura sugiere que los intereses, películas favoritas y otras listas deben agregarse en solicitudes POST por separado. Pero no creo que tenga sentido porque una de ellas podría fallar y luego habría una inserción parcial de la Persona y podría perder sus intereses o películas favoritas.

Answer 1

No creo que haya un problema al agregar todos los datos en una solicitud, siempre y cuando esté asociada inherentemente con el recurso principal (es decir, la persona en su caso). Si interesa, fav. las películas, etc. son recursos propios, también deben manejarse como tales.

Answer 2

Diría que depende completamente de la direccionabilidad y la exclusividad de los datos dependientes.

Si sus datos asociados al usuario dependen del usuario (es decir, una cadena "distinta", por ejemplo, un atributo como una cadena que representa un nombre (no validado) de una película), debe incluirse en el POST creación de la representación del usuario; sin embargo, si los datos son independientes del usuario (donde los datos se pueden direccionar independientemente del usuario, por ejemplo, una referencia, como una película de un conjunto de películas), entonces se debe agregar de forma independiente.

El razonamiento detrás de esto es que la adición de referencia cuando se incluye con el POST original implica transaccionalidad; es decir, si otro usuario elimina la referencia de película para la película "favorita" entre cuando se elige en el cliente y cuando se realiza el POST, el usuario agregará (debería por ese diseño) error, mientras que si la película "favorita" no es asociativo, sino que es solo un atributo, no hay nada sobre lo que fallar (los atributos (presumiblemente) no pueden ser invalidados por un tercero).

Y una vez más, esto va muy a sus necesidades específicas, pero me quedo del lado de permitir las inserciones parciales e indicar las fallas. La forma correcta de manejar este tipo de cosas si realmente no quiere permitir insertos parciales es simplemente implementar transacciones en el back-end; son la única forma de manejar verdaderamente una situación en la que un recurso asociado crítico se elimina a mitad del proceso.

Answer 3

La restricción real en REST es que para un recurso modificable que OBTENGA, también puede cambiar y PONER la misma representación para cambiar su estado. O POST. Dado que es razonable (y muy común) obtener recursos que son grandes paquetes de otras cosas, es perfectamente razonable PONER grandes paquetes de cosas, también.

Piense en los recursos en REST de manera muy amplia. Pueden mapear uno a uno con las filas de la base de datos, pero no es necesario. Un recurso direccionable puede incorporar otros recursos direccionables o incluir enlaces a ellos. Siempre que respete su representación y la semántica de las operaciones del protocolo subyacente (es decir, HTTP GET POST PUT, etc.), REST no tiene nada que decir sobre otras consideraciones de diseño que puedan hacer su vida más fácil o más difícil.