URI中的REST父ID

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

當在Child執行更新操作，通常childId是我需要的，以便唯一識別正確Child，認爲在路徑冗餘的parentId段。隨着層次結構變得複雜，這種冗餘會加劇。

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

目前，我想，也許沒有等級應出臺REST API，除非它是絕對直觀的，因爲它：

有沒有辦法避開這種冗餘，仍然符合REST原則？

來源

2012-02-19 yair

REST是一套原則，而不是一個標準。 – gioele 2012-02-19 18:33:50

什麼是URI的「結果」？（有人使用任何類型的API希望能夠預測操作的結果，至少在基本水平上。） – 2012-02-19 18:44:07

@DonalFellows - 訪問URI的結果。我編輯了你的問題:)。問題是這種API不夠可預測。 – yair 2012-02-19 18:49:36

是，僅僅構造你的URL是這樣的...

/children/{childId}

既然你可以推斷在服務器端的孩子家長，沒有理由宣佈它的URL。您絕對需要時只應將多個資源放在網址中。例如，用戶對評論進行投票。由於沒有正式的方式，以確定在數據庫端，你將創建一個URL如..

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

2012-02-19 18:19:03 Dave

所以你說的是我的觀察是正確的，對吧？有沒有可以添加的參考鏈接？謝謝。 – yair 2012-02-19 20:09:41

是的，你觀察到你顯示的url結構是多餘的是正確的。但說實話，我不知道從頭頂上的一個很好的參考。如果其他人發現了更詳細的說明或引用說明/等的好文章/參考資料，然後上傳/接受他們的答案。 – Dave 2012-02-19 20:28:55

由於REST指的是資源，他們並不一定是分層的。

在類似的API中，我有章節，類別和文章。當然，這些中的每一個都屬於另一個，但在REST中，我將它們指定爲/ {id} &文章/ {id}。他們仍然是個人資源的鏈接 - 但由於他們可以獨立於他們的父母，所以層次結構在URI中指定並不重要。

如果您確定要在URI中指定層次結構，則應該檢查以確保父項是子項的父項，並且另外引發錯誤 - 以保持層次完整性。

TL; DR

2012-02-19 18:21:00 Navarr

看起來戴夫和你說的有點相同，所以我會問你同樣的問題：我的觀察是否正確，然後呢？有沒有可以添加的參考鏈接？謝謝。 – yair 2012-02-19 20:10:34

這有點多餘，我認爲你不能找到真正的參考鏈接。畢竟REST是一種方法論。考慮這樣：OOP。你有對象。有時候，他們只與他們的父母有關，而有時候他們是獨立的。後者是你在我給出的結構中所反映的。 – Navarr 2012-02-20 05:07:56

對我這個問題的答案是要通過數據建模來驅動，並對問題的數據建模是「對子模型使用組合鍵」，如果他使用組合鍵，那麼如果不是，則必須將父ID放在URI中，並且child具有其自己的非複合ID，因此您可以將URL與僅限兒童身份證。

所以這是數據建模的問題！

2013-09-04 15:08:00

回答