假设我想设计一个关于歌曲、专辑和艺术家的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语义中,通过响应资源创建并提供一个包含已由请求导致修改的资源链接列表的表示来使副作用显式化,但这仍然不符合REST原则。