rest - 在 REST API 中处理非常深的关系

Question

我正在构建一个 REST API，并且我有一些关系使我的链接很长。他们对我来说很有意义，但这是一团糟。我不确定处理此问题的最佳方法是什么。这么长的链接有问题吗？我这样做违反原则了吗？我该如何处理这样的关系？

下面的例子有点做作，但它说明了我正在尝试做的事情。

一个公司有很多部门。每个部门都有很多员工。每个员工可以拥有多台计算机。每台计算机上都可以有很多文档。

GET 特定文档的路径是:

/companies/:companyId/departments/:departmentId/employees/:employeeId/computers/:computerId/documents/:documentId

每个 ID 在该层内都是全局唯一的——在整个系统中没有两个文档 ID 是相同的，但文档 ID 可以与员工 ID 相同。

这对我来说很有意义，因为每一层都只与它上面的一个事物相关联。一个部门将只属于一个公司，一个员工只属于一个部门，一台计算机只属于一个员工，一份文件只属于一台计算机。

我可以将它们分解成单独的端点，例如 /computers，但是我怎么知道在哪里分解它们呢？为什么我会选择 /computers 而不是 /employees/:employeeId/computers 作为端点？

Answer 1

在这个例子中，我会将这些资源中的每一个都移到顶级。每个顶级资源都可以有下一个“级别”作为成员。所以，

/companies
/companies/{id}
/companies/{id}/departments
/departments
etc..

如果最终用户确实需要操作集合的内容，我只会添加子资源。

深度嵌套的资源是有问题的。 3 个月后，如果您收到业务要求，要查找为公司 {id} 工作的所有员工(无论部门如何)，会发生什么情况？将员工作为顶级资源，您可以添加对 GET/employees?companyId={id} 的支持。在您上面展示的设计中，您的选择都是错误的。当您像现有的那样形式化嵌套结构时，您放弃的资源之间的关系有很大的灵 active 。

就您的一些具体问题而言:

I'm building a REST API

REST 在 URI 设计方面完全不可知。

I have some relationships that are making my links very long. They make sense to me, but it's a mess. [..] Is it a problem to have links that are so long?

希望最终用户永远不会输入这些内容。如果您的 API 确实是 RESTful，那么客户将使用您返回的链接，他们也不应该输入这些链接。在 RESTful 系统中，我希望“我有一些 X”关系保存在链接中，而不仅仅是通过 URI 的形状记录。我同意它们偏长，并且出于上述原因我会更改它们，但我认为您的具体顾虑不是更改它们的充分理由。

Am I violating a principle with these?

据我所知不是。