rest - REST 嵌套资源的最佳实践是什么？

Question

据我所知，每个单独的资源应该有 只有一个规范小路。那么在下面的例子中，好的 URL 模式是什么？

以公司的休息表示为例。在这个假设的例子中，每个公司 拥有 0个或多个部门和每个部门拥有 0 名或更多员工。

A部不能存在 没有关联公司。

一名员工 不能存在 没有相关部门。

现在我会发现资源模式的自然表示。

/companies公司集合 - 接受新公司的认沽权。获取整个集合。

/companies/{companyId}个人公司。接受 GET、PUT 和 DELETE

/companies/{companyId}/departments接受新项目的 POST。 (在公司内创建一个部门。)

/companies/{companyId}/departments/{departmentId}/

/companies/{companyId}/departments/{departmentId}/employees

/companies/{companyId}/departments/{departmentId}/employees/{empId}

考虑到限制，在每个部分中，如果嵌套得有点深，我觉得这是有道理的。

但是，如果我想列出( GET )所有公司的所有员工，我的困难就来了。

资源模式最接近地映射到 /employees (全体员工合集)

这是否意味着我应该有 /employees/{empId}还因为如果是这样，那么有两个 URI 可以获取相同的资源？

或者也许整个模式应该扁平化，但这意味着员工是一个嵌套的顶级对象。

在基本层面 /employees/?company={companyId}&department={deptId}返回与最深嵌套模式完全相同的员工 View 。

资源为 的 URL 模式的最佳实践是什么？拥有由其他资源但应该单独查询？

Answer 1

你所做的是正确的。一般来说，同一个资源可以有很多 URI - 没有规则说你不应该这样做。

通常，您可能需要直接访问项目或作为其他内容的子集访问 - 所以您的结构对我来说很有意义。

仅仅因为员工可以在部门下访问:
company/{companyid}/department/{departmentid}/employees
并不意味着他们也不能在公司下访问:
company/{companyid}/employees
这将返回该公司的员工。这取决于您的消费客户需要什么 - 这就是您应该设计的。

但我希望所有 URL 处理程序使用相同的支持代码来满足请求，这样您就不会重复代码。