URI中的REST父ID

Question

假設我的模型由一個Parent實體組成，該實體通過children屬性引用一些Child實體。 根據REST原則，特定Child的URI的路徑段將是/parent/{parentId}/children/{childId} 。

對Child執行更新操作時，通常只需要childId就可以唯一地標識正確的Child ，從而認為路徑中的parentId段是多余的。 隨着層次結構變得復雜，這種冗余會加劇。

現在我想到了它，它也可能導致意外行為：如果程序員不知道，訪問具有相同childId但具有不同 parentId URI可能會導致相同的行為。 在不相關的Parent下訪問Child時可能發生的情況是應該返回客戶端錯誤代碼。

目前我認為可能沒有應該向REST API引入層次結構，除非它非常直觀，因為它：

1. 使URI（因此API）更復雜。 加強可維護性。
2. 冗余可能導致用戶推斷訪問某些URI的結果。
3. 冗余可能成為不知情的程序員的陷阱。

有沒有辦法逃避這種冗余並仍然符合REST原則？

Answer 1

是的，只需像這樣構建你的網址......

/children/{childId}

由於您可以從服務器端的子項推斷父項，因此沒有理由在URL中聲明它。 在絕對需要時，您應該只在URL中放置多個資源。 例如，用戶對評論進行投票。 由於在數據庫方面沒有正式的方法來確定，你可以創建一個類似的URL。

/voter/{userId}/comment/{commentId}/upvote

Answer 2

對我來說，這個問題的答案將由數據建模驅動，對於數據建模，如果他使用復合鍵，那么問題是“使用復合鍵是否為子模型”，因此如果不是，則必須將父ID放在URI中。 child有自己的id，它不是復合的，所以你只能使用帶有child id的URL。

所以這是數據建模問題!!!

Answer 3

由於REST指的是資源，因此它們不一定必須是分層的。

在類似的API中，我有章節，類別和文章。 當然，其中每個都在另一個之下，但在REST中我將它們指定為section / {id}＆article / {id}。 它們仍然是指向各個資源的鏈接 - 但由於它們可以獨立於其父級，因此在URI中指定層次結構並不重要。

如果您肯定要在URI中指定層次結構，則應檢查以確保父項是子項的父項，並在其他方面拋出錯誤 - 以保持層次結構的完整性。

TL; DR

• /父母/ {}的parentID
• /兒童/ {} childID的