什麼是REST風格的URL嵌套節點的好處

Question

是否有人可以幫助解釋設計一個RESTful API URL「正確」的方式的好處：

/api/companies/1/buildings/4/rooms/420

主場迎戰「不正確」的方式：

/api/rooms/420

好處我看到：

• 更容易閱讀的句子
• 容易推斷出「低級別」的資源可用（IMO最好的理由）

Q1難道我們假設房間＃420不應該在任何其他存在建造？我可以爭辯說這是數據庫指針，所以也許這就是我困惑的地方。

另一件事是，你不應該比窩深的幾個節點的更多：

/api/companies/1/buildings/4/rooms/420/desks/5/legs/3

Q2：在什麼時候，你打破了這些資源？或者這是否暗示如果這種情況發生，API設計需要重新思考？

Q3：在設計前端的網址，是然後 OK使其只.com/rooms/420？

謝謝:)

Answer 1

URIs不打算被讀作「句子」。您應該考慮URI是不透明的 - 它們不需要傳遞分層信息。 RESTful API使用資源之間的鏈接導航到其他信息。使用RESTful API的程序員使用文檔來辨別資源類型之間的關係。

API客戶端不知道或關心你的id是什麼。也許這是一個數據庫ID，也許不是。他們只知道URI api/rooms/420是識別特定資源的唯一方法。

Q1。 ？ 420號房間存在於任何地方。在room資源上粘貼building鏈接。客戶可以按照該鏈接查看房間的建築物。

Q2。 我打破它們，客戶會讓我一樣。 :-)給這個URI，客戶如何搜索所有擁有兩個以上窗口的房間，而不考慮建築物？或者所有被標記爲要扔掉的桌子，無論建築物是什麼？平面API給你比深度嵌套更靈活。

Q3。這從來都不是。然而，你決定設計它。我不清楚你的意思是「前端網址」。