使用REST API來查找依賴於上下文的列表

Question

我目前正在嘗試確定解決我在設計REST API時遇到的問題的最佳方法。

簡化方案是我的Web應用程序有兩個資源，例如部門和員工。 兩者都在業務層中受到安全控制。

可以存在一個有權訪問員工但不能訪問部門的用戶，但是，當該用戶編輯員工時，他們需要能夠從下拉列表中選擇該員工的部門（類似地，他們可能具有要過濾的員工列表）按部門）。

通常，該用戶將無權訪問部門對象，因此將無法調用/ department /，但是在編輯員工的情況下，他們需要部門列表。

建議的處理方式是什么，我將在/ employee /的每個GET上返回部門列表，還是會創建另一個由員工和部門對象組合而成的資源（部門是部門的完整列表）？

我目前無法更改對象的安全性，因為這在應用程序邏輯中已根深蒂固。

有人有想法嗎？

問候，加里

Answer 1

創建一個名為“ DepartmentList”的新資源

Answer 2

注意 ：我認為復數名稱更好。

您必須考慮什么會使您的用戶（開發人員）的生活變得更輕松。

合並的資源將“污染”您的api。 您的api將公開/ employees，/ departments和/ employeeDepartments。 我認為后者不應該在層次結構中那么高。

用戶使用起來也會有些復雜：

“要編輯員工，您需要設置一個部門，但是該部門並不總是在/ department中可用，因此最好從employeeDepartments中獲得它。”

考慮一下您的員工對象：GET / employees / 123

 employee:{
    name: John,
    ... 
    department: {
        id: ID
        --a subset of data--
    }
}

數據的子集應足以對沒有權限的用戶進行操作，而有權訪問的用戶可以在/ departments / ID上進行操作。

現在，如何獲取可用選項列表？

我過去常常提供一個“特殊”操作/ new，在那里我提供了一個“表單”，用戶可以將其用作發布和創建新資源的模板。 這不是采用的Rest“標准”，而是HATEOAS友好的-確實有助於發現您的api。

因此，GET / employees / new可以打印

 employee:{
    name: "",
    ... 
    department: [{ id: 1, --subset of data-- },{ id: 2, --subset of data-- }.. ]
}

格式上有一些約定（例如：用戶需要知道它只需要選擇一個部門）。 但這是一個新的空洞討論。