Question

我的问题是在为API目的构建URL时嵌套资源的优势。请考虑以下两种用于访问员工资源的备选方案：

/api/employees?department=1   # flat

Vs.

/api/departments/1/employees  # nested

现在考虑开发通用库以从API访问REST资源的任务。如果所有路由都是扁平的，那么这样的REST包装器库只需要知道所访问资源的名称：

store.query('employees', {department_id:1})   =>   /api/employees?department=1

但是，如果我们要支持嵌套路由，那么这个包装器需要知道有关嵌套模型和其他资源的额外信息，以便了解如何构建用于引用此类模型的URL。鉴于并非所有模型都嵌套在相同的父资源下，甚至一些模型根本不会嵌套，REST包装器库需要有某种配置来描述所有这些不需要的额外知识否则。

所以我的问题是：

API中的嵌套资源路由是否有任何实际优势？（这并不意味着最终用户使用，因此从拥有更漂亮的URL获得的收益更少。）
嵌套方法是否真的比平面更好，超越美学，以证明为支持资源URL构建缺乏统一性而引入的额外努力和复杂性是合理的？

另请参阅：https://stackoverflow.com/a/36410780/621809

更新：重要的澄清

我从一些评论和答案中了解到，我对一个方面不够清楚：我不反对使用/employees/5或/departments/1等网址处理单个资源。我不认为这是嵌套的。

当我说嵌套资源时，我指的是像/departments/1/employees这样的URL，其中资源总是在另一个资源的上下文中被寻址。主要问题是用于URL构建，通用库需要知道额外的东西喜欢＆＃34;员工嵌套在部门之下＆＃34;但＆＃34;分支没有嵌套在任何东西下＃34;。如果所有资源都可以通过REST来解决，但是以平面方式解决，知道如何解决它们会更简单，更容易预测。

当您考虑它时，在数据库中您不需要知道额外信息，以便知道如何处理对象集合（例如RDMS中的表）。您始终将员工集合称为employees，而不是departments/5/employees。

Answer 1

如果您想要深入了解更多级别会发生什么？

/api/addresses?departmentId=1&employeeId=2&addressId=3

VS

/api/departments/1/employees/2/addresses/3

地址端点突然变得臃肿，带有参数。

此外，如果您正在查看Richardson Maturity Model level 3，则RESTful API可通过链接发现。例如，从顶级，例如/ api / version（/ 1），您会发现有一个指向部门的链接。以下是HAL浏览器等工具的外观：

"api:department-query": {
  "href": "http://apiname:port/api/departments?pageNumber={pageNumber}&pageSize={pageSize}&sort={sort}"
},
"api:department-by-id": {
  "href": "http://apiname:port/api/departments?departmentId={departmentId}"
}

（可以是最终以分页方式列出所有查询的查询，或者直接指向特定部门的参数化链接，前提是您知道该ID）。

这里的优点是客户端只需要知道关系（链接）名称，而服务器大部分都可以自由地改变关系（和资源）URL。

Answer 2

我将基于模型和安全性投票支持第二解决方案。

该部门位于路径中，并且不必位于有效负载中，无论是读取还是写入。

如果要更改员工的派遣方式，则depID可以包含在有效负载中，也可以通过单独的端点（具有单独的授权）/ employees / {ID}来包含。

Answer 3

旧帖子，但对我来说不是令人满意的答案。

这取决于您的 API。如果您的数据是分层的并且不需要访问资源而无需通过其父项过滤它们，那么嵌套是可以的（并且也不是嵌套的）。

如果您的 id 很长 (GUID)，您的层次结构很深，或者您需要访问任何资源而无需通过其父项进行过滤，那么不嵌套是一个不错的选择。

尽量有一个统一的界面，不要有很多方法来访问相同的资源。

试试这个可以更好地解释这一点的链接：https://www.moesif.com/blog/technical/api-design/REST-API-Design-Best-Practices-for-Sub-and-Nested-Resources/

Answer 4

根据我的经验： Q1。由于关系模型，易于使用，难以实现 Q2。对于权限以及在降级之前可以执行的其他潜在检查，嵌套更好

RESTful API路由设计：嵌套与非嵌套

4 个答案: