RESTful API中的动态资源

这个标题有很多问题，但读过它们后，我不认为它们中的任何一个回答了我的特定问题。RESTful API中的动态资源

我在设计我喜欢称之为“REST风格的互联网点唱机”。基本上，这是一个REST风格的api，可以通过搜索查询访问各种互联网音乐服务（如youtube），下载音乐并将其添加到MPD播放列表中。我已经实现了一个原型，它的工作很好，但我不喜欢我的API的设计，特别是关于播放列表管理。

现在，我有一个播放列表端点，启用了“GET”和“PUT”。现在，get返回每首歌曲的JSON表示列表（保存的歌曲的文件名及其长度）。 Put允许您，如果您知道所有保存的音乐的文件名，请放置这些JSON表示的列表并替换当前的播放列表。

我想让每首歌曲资源都由它在当前播放列表中的位置来标识，并且能够单独获取/放入/删除它们。我的问题在于，如果我删除了资源ID 5（播放列表中的第5首歌），那么第6首歌会上移到第5个位置并成为该资源。随着播放列表的移动，显然这些ID将会移动。这听起来不太舒服。我觉得如果你删除了一个资源，它不应该被重新填充，除非你在那里放置了某些东西。这是否是可以原谅的？有没有更好的方式来处理播放列表管理更安宁的方式？

在此先感谢您的帮助！

来源

2014-11-14 Dan Cauley

如果在列表中没有插入任何项目或从列表中删除项目，则顺序只会是您使用上述列表的方式中的有效标识符。维持秩序作为每个项目的额外属性并提出另一种身份机制将是更可行的。

我想你可能需要想出另一种方法来识别播放列表中的曲目，也许或uuid就足够了。如果您想在UI中保留该行为，则序列可以是播放列表中每个播放列表项的属性。

来源

2014-11-14 21:06:38

使用您的歌曲的专用标识。如果您创建一个新的歌曲，（通过POST），您为其分配一个连续号码作为ID，您将在服务器端执行此操作。

创建资源播放列表其持有

Collection<Song> songs; // in class Playlist

的歌曲

。这些映射是从播放列表到歌曲的一对多映射。

资源可能看起来像：

/playlist/1001/position/10

及以后，你可以实现

.../playlist/1001/last , /playlist/1001/shuffle , ...

的位置，然后通过类似PUT使用：

PUT : /playlist/1001/position/10/song/2003

和消费的

GET : /playlist/1001/position/10

甚至

/playlist/1001/position/next

而且

/playlist/1001/position/reset ...

你可以把它的球员，然后去

/playlist/1001/player/reset

或者把它放在请求体。

PUT: /playlist/1001  
    { "player" : "reset" } 

PUT: /playlist/1001 
    { "songId" : "3021_MYUIDSCHEMA" }

也许这个 “前加上”： “真正的”

然而，如果你这样的球员。您的GET将有“sideeffect”，玩家收益...或者你不动的“指数”，直到一个使得

PUT: /playlist/1001 
{ "skip" : "1", // for next or more 
    "set" :: "10" // for direct set }

但是，单独使用

/playlist/xyz/positions/...

非常有意义。

将id作为序号是反正不是好主意。

简而言之：你有2选择：

您去除前期实体后改变位置

(id: 5 becomes id: 4)

时更改实体的ID。

，或者您更改位置

(positions[4]: 5 /*where it was before*/ positions[4]: {otherSongsId}

这将是一个明确的开始从中，可以随后逐渐演变。

来源

2016-07-11 17:41:38 Lemonade

RESTful API中的动态资源

回答

相关问题