处理资源之间双向关系的 RESTful 方式

Question

假设我想设计一个 REST api 来讨论歌曲、专辑和艺术家(实际上我就是这样做的，就像我之前的 1312414 个人一样)。

歌曲资源始终与其所属专辑相关联。相反，专辑资源与其包含的所有歌曲相关联。这些关联通过链接的方式在资源表示中表达。

因此，表示形式将如下所示:

{
   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: '...' }
   ]
}

鉴于我希望这一点成立(也许问题出在“给定”)，那么我该如何设计我的 API，以便专辑或歌曲资源的创建不会对以前存在的产生副作用歌曲或专辑资源？

这是某种先有鸡还是先有蛋的问题。如果我首先创建歌曲资源 (POST/songs/)，然后创建专辑资源 (POST/albums/)，则歌曲资源会作为专辑创建的一部分进行修改(根据 REST 原则，这是不好的)，因为关联两个资源之间的关系正在服务器上更新。对于我先创建专辑，然后创建歌曲的场景也是如此。

我想我可以通过避免服务器上的副作用并将管理双向关系的负担转移给客户端来避免整个问题。

此外，我不希望专辑和歌曲作为一个整体自动创建。

我现在唯一能想到的是，通过使用包含已修改资源的链接列表的表示来响应资源创建，从而在我的 API 语义中包含上述副作用的请求。这使得副作用显而易见，但仍然令人不安。

Answer 1

关于 REST，没有任何内容表明对一种资源的状态的操作不能改变另一种资源的状态。 REST 与此最接近的是幂等操作的概念，它只是说重复这些操作将导致相同的状态。

因此，就您的情况而言，Song 资源能够有效地将自身添加到 Album 资源中并没有本质上的错误。 Album 资源能够说 Song 资源是它的一部分，这也没有什么本质上的错误。

现在，考虑到您的业务需求，您可能需要 a.) 更改歌曲/专辑的表示方式，或者 b.) 允许歌曲/专辑以 m/m 方式相关，而不是 1/1。原因是，根据您在系统中构建数据和选择资源(即可寻址单元)的方式，您实际上正在建模不同的数据关系，我认为这是您面临的问题的关键.

使用 Songs 和 Albums 系统中的独立资源，强制实现更具限制性的关系(例如 1/1 而不是 m/m)，需要在您的系统中进行更多的工作和规范。内容类型。您必须处理两个不同专辑都认为它们包含一首歌曲的情况，但 1/1 关系不允许这样做。

如果您有一个 Album 对象，明确包含或拥有 Song 对象，那么就很少有问题，因为Album只能操作它自己的歌曲，而不能操作任何其他Album的歌曲。然而，这改变了数据模型，因为歌曲不再是一等公民，而是位于拥有它们的专辑之下。

这是整个问题的关键点...你必须决定谁拥有这段关系。

双方(专辑和歌曲)拥有它都没有问题。这对于 m/m 关系非常有效，但对于 1/1 关系，则需要更多的管理开销(即其他东西实际上拥有该关系)。

但是，如果您想要 1/1 关系而无需所有开销，则必须让一个参与实体拥有该关系，这意味着只有一个> 更改它的路径...通过拥有实体。