0
我看到的大多數示例都使用REST URL模式（如http://www.app.com/books/1）來訪問ID爲1或http://www.app.com/books的圖書以訪問所有圖書。針對具有多個公司或組織的系統的REST API設計
這很好，但我通常在支持多家公司的應用程序上工作。例如，公司ABC有2個用戶，公司DEF有2個用戶。來自公司ABC的用戶創建了一本書，其ID爲100。現在，當一個RESTful打來的電話用戶排在公司DEF：
http://www.app.com/books/100
有將需要訪問異常，或者
http://www.app.com/books
只會列出所有書籍屬於到DEF（不是新的ID爲100的書）。對於像Book這樣的許多實體，公司ID是表格的一部分，但對於其他實體可能並非如此。例如，如果書中的某一章有一個REST操作，則章節表將具有對本書的外鍵引用，但不包括公司。
對於管理對此資源的訪問，最佳做法是什麼？如果來自DEF的人試圖訪問ABC的一章，我將不得不構建一個查詢以加入書中的章節來驗證公司ID是否有效。
我正在使用Grails 3.x，其中大部分邏輯被抽象並認爲「自動」發生。因此，自動返回針對特定書籍ID的URL，並且列出所有內容的請求將返回數據庫中的每本書籍。看起來要繼續，我將不得不覆蓋大部分自動功能並實現我自己的安全性，可能在服務層中公司ID將成爲每個操作的必需參數。這聽起來合理嗎？
是否有這種事情的既定最佳實踐？
在大多數情況下，我們增加安全性基礎上查詢用戶在服務器端登錄信息（使用SpringSecurityPlugin）（客戶端甚至不知道它是查詢的一部分）。簡單地說，無論何時我們想要list（），我們都會使用findByCompany（）和findByIdAndCompany，或者在所有REST請求的搜索中添加Company作爲條件。 Book域的一部分將是創建它/有權訪問的公司（或公司集合）。 – billjamesdev
準確地說 - 使用SpringSecurity通過請求頭中的令牌對每個請求進行身份驗證。之後，您可以實施任何您想要的邏輯，並且您的應用程序將知道哪家公司要求提供數據。檢查：** org.grails.plugins：spring-security-core **和** org.grails.plugins：spring-security-rest ** –