我有一個Post實體列表，每個帖子都有一個Comment實體列表。 Post實體是一個構圖對象。沒有帖子的系統中沒有評論。 URI的在REST API中創建「假」ID
實施例：
/posts/3453/comments/8547
此檢索一個特定的評論，並且也用於刪除和更新特定註釋。現在，那豈不是更好，如果我的API有這樣的事情：
/posts/3453/comments/1
凡評論編號8547的第一個URI是一樣的最後，但ID爲的情況下帖子。它從一開始，隨着更多評論的添加而增加。然而，如果你有10條評論，其ID爲1-10，那麼刪除數字5，是否應該以某種方式更新ID以便1-9適用？
這是否合理？我剛開始考慮它，還是應該使用數據庫中唯一的ID（主鍵）？如果不是，你會如何創建這種IDS？
如果您選擇按序號標識註釋，那是您的偏好。如果在應用程序的概念中，將註釋的唯一標識作爲與帖子標識符相關的序列號是有意義的，只要有文檔記錄，這是完全精細的設計。
您的重新排序方法至少有兩個重大缺陷，這可能會導致您的應用程序URI設計有缺陷。第一個失敗，就是URI上的GET方法應該是可緩存的，重新排序會打破這個契約，因爲第2項沒有改變，但是因爲第1項你現在改變了/ 2的含義。接下來，這顯然會破壞人們可能創建的鏈接。
我喜歡序列查詢參數的概念，但是我認爲從我對您的問題的有限理解到僅僅使用標識符是有道理的，因爲我上面列出的兩個缺陷不再是問題。
而不是使用索引方案，我肯定會去評論的實際ID。原因是如果一行中有多個更新會發生什麼？用戶A刪除索引2處的評論，同時用戶B刪除索引3處的評論。那麼，哪些評論應該真正刪除？實際刪除將由執行順序決定。如果您使用真實身份證，則您沒有任何爭用。
的數字8547和1只能看是相同的，但它們代表不同的概念：8547是標識符，而1是序列號。序列號可以更改，但ID不可更改。
我會建議使用URI的ID識別具體評論資源，並添加一個快速反應小組與查詢能力通過其序列號搜索評論資源，就像這樣：
/posts/3453/comments?sequence=1
這樣有不會有關於「規範」資源URI的問題，但客戶端將能夠查詢註釋而不必提供完整的標識。