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中的動態資源

回答

相關問題