RESTful Web 服務——嵌套資源需要很多請求

Question

關於小型管理軟件的 REST API 設計，我有一個小問題。 后端在 Spring 中實現，前端在 angular 中實現。 建築物、房間和工作場所在軟件內進行管理。

該接口目前為此目的具有以下端點：

• /locations/buildings[/%buildingId%]
• /locations/building/%buildingId%/rooms
• /locations/rooms[/%roomId%]
• /locations/rooms/%roomId%/workplaces
• /locations/workplaces[/%workplaceId%]

返回的 JSON 對象未嵌套並包含 HATEOAS 鏈接。 該工具中維護的事件大多與工作場所有關。 這意味着我通常必須首先通過 REST 查詢事件。 這些包含 WorkplaceId 和 Workplace 的鏈接。 由於您一開始不能對工作場所做任何大事，因此必須通過鏈接查詢房間，最后是建築物。

對於個別事件，這仍然可以正常工作。 但是，如果我想列出所有工作場所，包括房間和建築物，例如，我有很多要求。

例子：

• 2棟
• 每棟60間客房
• 每個房間 3-4 個工作站

1. 獲取建築物（1 個請求）
2. 獲取相關房間（每棟建築 1 個請求 = 總共 2 個）
3. 為每個房間獲取工作站（每個房間 1 個請求 = 總共 120 個）

后者讓我很困擾。 為了稍微緩和一下整個事情，我可以在啟動應用程序時拿起整個事情，然后總是參考這個數據庫。 不幸的是，整個事情都很丑陋，因為我必須定期檢查其他用戶是否進行了更改。

我的下一個想法是結合 API 級別的房間和工作場所，並返回房間級別的嵌套對象。 但是端點/locations/workplaces/%workplaceId%應該仍然存在，以便我可以正確鏈接事件？

Answer 1

大多數超媒體格式都具有通過嵌入請求來減少請求的功能。 例如，如果您使用 HAL 格式，則可以使用_embedded 。

這個嵌入式結構中的所有內容仍然有一個 URI，我會說建議您也使對這些端點的 GET 請求工作相同。

我們的客戶端（ ketting ）將透明地處理_embedded ，因此如果服務器嵌入了東西，它只會預先填充緩存，但稍后可能仍需要刷新特定端點而不再次獲取整個列表，那就是那些單獨的 GET 請求仍然很方便。

為避免輪詢，您始終可以考慮設置 websocket。 在我們處理 websocket 的系統中，它只是發出了一個已更改的 URI 列表，然后客戶端只需對這些 URI 執行GET請求。