Json RESTful API中的动态资源

有很多关于这个题目的问题，但是读过之后，我认为没有一个能回答我的问题

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

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

我希望每个歌曲资源都能通过它在当前播放列表中的位置来识别，并且能够单独获取/放置/删除它们。我这里的问题是，如果我删除资源ID 5播放列表中的第5首歌曲，那么第6首歌曲将上移到第5位并成为该资源。随着播放列表的移动，显然这些ID会移动。这对我来说听起来不太舒服。我觉得如果你删除了一个资源，它就不应该再被填充，除非你把一些东西放在那里。这可以原谅吗？有没有更好的方法可以以更安全的方式处理播放列表管理

---

提前感谢您的帮助

如果在列表之间没有插入项目或从列表中删除项目，则序列仅在您使用上述列表的方式中是有效的标识符。更可行的做法是将秩序作为每个物品的额外属性来维护，并提出另一种身份机制

---

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

为歌曲使用唯一标识符。 如果您通过POST创建了一首新歌，您将为它分配一个序列号作为id，您将在服务器端执行此操作

创建一个资源播放列表，其中包含

Collection<Song> songs; // in class Playlist

除此之外，您还可以实施

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

然后通过PUT like使用位置：

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

和消费：

GET : /playlist/1001/position/10

甚至

 /playlist/1001/position/next

及

你可以称之为player，然后选择

/playlist/1001/player/reset

或者把它放在请求主体中

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

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

也许用这个 预编：对

但是如果你实现了这样一个播放器。你得到的将有副作用，玩家继续。。。或者，直到有人做出选择，您才移动索引

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

但是，单独使用

/playlist/xyz/positions/...

这很有道理

无论如何，把id作为序号是不好的

简而言之：您有两种选择：

更改位置时，可以更改实体的id

(id: 5 becomes id: 4)

删除前端实体后

或者你改变立场

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

这将是一个明确的开始，然后你可以逐渐进化

(id: 5 becomes id: 4)

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