REST嵌套資源的最佳實踐是什么？據我所知，每個資源應該只有一個規范路徑。因此，在下面的示例中，優秀的URL模式是什么？以公司的休息代表為例。在這個假設的例子中，每個公司擁有 0個或更多部門，每個部門擁有 0個或更多員工。沒有關聯公司，部門就不可能存在。沒有相關部門，員工就不能存在?，F在我會找到資源模式的自然表示。/companies 一系列公司 - 接受新公司的接受。獲取整個系列。/companies/{companyId}一家公司。接受GET，PUT和DELETE/companies/{companyId}/departments接受新項目的POST。（在公司內部創建一個部門。）/companies/{companyId}/departments/{departmentId}//companies/{companyId}/departments/{departmentId}/employees/companies/{companyId}/departments/{departmentId}/employees/{empId}考慮到約束，在每個部分中，我覺得如果有點深度嵌套，這是有道理的。但是，如果我想列出（GET）所有公司的所有員工，我的困難就來了。最合適的資源模式將映射到/employees（所有員工的集合）這是否意味著我應該/employees/{empId}也是因為如果是這樣，那么有兩個URI可以獲得相同的資源？或者整個架構可能會被夷為平地，但這意味著員工是一個嵌套的頂級對象。在基本級別，/employees/?company={companyId}&department={deptId}返回與最深層嵌套模式完全相同的員工視圖。URL模式的最佳實踐是什么，其中資源由其他資源擁有但應該可以單獨查詢？更新：請參閱下面的答案，看看我做了什么。
3 回答
牛魔王的故事
TA貢獻1830條經驗 獲得超3個贊
你所做的是正確的。通常，同一資源可能有許多URI - 沒有規則表明您不應該這樣做。
通常，您可能需要直接訪問項目或作為其他內容的子集 - 因此您的結構對我來說很有意義。
僅僅因為員工可以在部門下訪問：
company/{companyid}/department/{departmentid}/employees
并不意味著他們也無法在公司下訪問：
company/{companyid}/employees
哪個會讓該公司的員工回歸。這取決于您的消費客戶需要什么 - 這就是您應該設計的內容。
但我希望所有URL處理程序使用相同的支持代碼來滿足請求，這樣您就不會復制代碼。
慕妹3242003
TA貢獻1824條經驗 獲得超6個贊
我嘗試了兩種設計策略 - 嵌套和非嵌套端點。我發現：
如果嵌套資源具有主鍵并且您沒有其主鍵，則嵌套結構要求您獲取它，即使系統實際上并不需要它。
嵌套端點通常需要冗余端點。換句話說，您通常需要額外的/員工端點，以便獲得跨部門的員工列表。如果您有/員工，/公司/部門/員工到底會給您帶來什么？
嵌套端點不會很好地發展。例如，您現在可能不需要搜索員工，但您可能稍后會進行搜索，如果您有嵌套結構，則別無選擇，只能添加另一個端點。使用非嵌套設計，您只需添加更多參數，這更簡單。
有時資源可能有多種類型的父母。導致多個端點都返回相同的資源。
冗余端點使得文檔更難編寫，也使得api更難學習。
簡而言之，非嵌套設計似乎允許更靈活和更簡單的端點模式。
幕布斯6054654
TA貢獻1876條經驗 獲得超7個贊
我把我從問題所做的事情轉移到了更多人可能會看到它的答案。
我所做的是在嵌套端點上創建創建端點，修改或查詢項目的規范端點不在嵌套資源上。
所以在這個例子中（只列出更改資源的端點）
POST/companies/創建新公司返回創建公司的鏈接。POST/companies/{companyId}/departments當一個部門被放置創建新部門返回一個鏈接/departments/{departmentId}PUT/departments/{departmentId}修改一個部門POST/departments/{deparmentId}/employees創建一個新員工返回一個鏈接/employees/{employeeId}
因此，每個集合都有根級資源。然而，創建是在擁有對象中。
添加回答
舉報
0/150
提交
取消