使用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-- }.. ]
}

格式上有一些约定（例如：用户需要知道它只需要选择一个部门）。 但这是一个新的空洞讨论。