Forma RESTful de tratar con las relaciones bidireccionales entre los recursos

Question

Supongamos que quería diseñar una APLICACIÓN REST que habla de canciones, álbumes y artistas (en realidad lo hago, como 1312414 personas antes que yo).

Un recurso de canción siempre está asociado con el álbum del que forma parte. Por el contrario, el recurso del álbum está asociado con todas las canciones que contiene. Las asociaciones se expresan en las representaciones de recursos a través de enlaces.

Como tal, las representaciones se vería algo como esto:

{ 
    song: 'xyz', 
    links: [ 
     { rel: 'album', url: '.../albums/abc' } 
    ] 
} 

{ 
    album: 'abc', 
    links: [ 
     { rel: 'song', url: '.../songs/xyz' }, 
     { rel: 'song', url: '...' }, 
     { rel: 'song', url: '...' }, 
     { rel: 'song', url: '...' } 
    ] 
} 

dado, que yo quiero que esto se mantenga verdadera (tal vez el problema radica en la "Dada"), ¿cómo puedo diseñar mi API , tal que la creación de un álbum o recurso de canción no tiene efectos secundarios en recursos de canciones o álbumes previamente existentes?

Esto es una especie de problema de huevo/gallina. Si creo primero un recurso de canción (POST/songs /) y luego creo un recurso de álbum (POST/albums /), el recurso de la canción se modifica como parte de la creación del álbum (lo cual es malo según los principios REST), porque la asociación entre los dos recursos se está actualizando en el servidor. Del mismo modo para el escenario donde primero creo el álbum, la canción es el segundo.

Creo que podría evitar todo el problema evitando los efectos secundarios en el servidor y pasando la carga de administrar las relaciones bidireccionales al cliente.

Además, no quiero que se creen álbumes y canciones como un todo.

Lo único que puedo pensar ahora es incluir el efecto secundario antes mencionado en la semántica de mi API respondiendo a una creación de recursos con una representación que contiene una lista de enlaces a recursos que se han modificado como resultado de la solicitud. Eso hace que el efecto secundario sea explícito, pero aún así no es tranquilo.

Answer 1

Nada sobre REST dice que la manipulación del estado de un recurso no puede alterar el estado de otro recurso. El REST más cercano que llega a eso es la noción de acciones idempotentes, que dicen solo que repetirlas dará como resultado el mismo estado.

Por lo tanto, en su caso, no hay nada intrínsecamente incorrecto en que un recurso Song pueda, efectivamente, agregarse a un recurso Album. Tampoco hay nada intrínsecamente incorrecto en que un recurso Album pueda decir que un recurso Song es parte de él.

Ahora, dados los requisitos de su negocio, es posible que desee: a) Cambiar la forma en que representa las canciones/álbumes o b) Permitir que las canciones/álbumes se relacionen en m/m en lugar de 1/1. La razón de esto es que, dependiendo de cómo estructure sus datos y seleccione recursos (es decir, unidades direccionables) en su sistema, en realidad está modelando relaciones de datos diferentes, y creo que este es el quid de la cuestión que está enfrentando. .

Con Songs y Albums recursos separados en su sistema, imponiendo relaciones más restrictivas, como 1/1 en lugar de m/m, requiere mucho más trabajo y especificación en sus tipos de contenido. Tienes que manejar los casos donde dos álbumes diferentes piensan que contienen una sola canción, pero una relación 1/1 no lo permite.

Si usted tiene un objeto Album explícitamente contener o propiosSong los objetos, entonces hay un problema menor, ya que un Album sólo puede manipular a su propias canciones y no las de cualquier otra Album. Este cambia el modelo de datos, sin embargo, ya que Songs ya no son ciudadanos de primera clase, sino que son debajo de el álbum que los posee.

Este es el punto clave de todo el problema ... debe decidir a quién pertenece la relación.

No hay nada de malo en que ambas partes (Album y Song) lo tengan. Esto funciona perfectamente para una relación m/m, pero para una relación 1/1, eso requiere mucha más sobrecarga de administración (es decir, otra cosa realmente posee la relación).

Si quieres una relación 1/1 sin todos los gastos generales, sin embargo, usted tiene que tener una de las entidades participantes son dueños de la relación, lo que significa que sólo hay una camino a través de cambiarlo ... la entidad propietaria.