Question

我目前正在尝试确定解决我在设计REST API时遇到的问题的最佳方法。

简化的场景是我的Web应用程序有两个资源，例如部门和员工。两者都是业务层内的安全控制。

可以存在可以访问员工但不能访问部门的用户，但是当该用户编辑员工时，他们需要能够从下拉列表中选择该员工的部门（类似地，他们可能拥有他们的员工列表）想按部门过滤。）

通常用户无法访问部门对象，因此无法调用/ department /例如，但在编辑员工的情况下，他们需要部门列表。

建议的处理方法是什么，我会在每个GET / employee /上返回一个部门列表，或者我会创建另一个资源，它是员工和部门对象的组合（部门是完整列表部门）？

我目前无法更改对象的安全性，因为这在应用程序逻辑中根深蒂固。

有人有任何想法吗？

此致加里

Answer 1

创建一个名为'DepartmentList'的新资源

Answer 2

注意：我认为复数名称更好。

你必须考虑什么会让你的用户（开发者）的生活更轻松。

合并后的资源会“污染”你的api。您的api会暴露/员工，/部门和/ employeeDepartments。我不认为后者应该在层次结构中那么高。

您的用户使用它也会更复杂：

“要编辑员工，您需要设置一个部门，但是部门并不总是在/部门可用，所以最好从employeeDepartments获取...”

想想您的员工对象：GET / employees / 123

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

数据子集应足以为没有权限的用户操作，具有正确访问权限的用户可以在/ departments / ID上操作。

现在，如何获取可用选项列表？

我用来提供一个'特殊'动作/新动作，我提供一个'表单'，用户可以将其用作模板来发布和创建新资源。这不是采用的Rest'标准'，但是HATEOAS友好 - 它确实有助于你的api的发现。

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

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

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