REST嵌套资源的最佳做法是什么? [英] What are best practices for REST nested resources?
问题描述
据我所知，每个单独的资源应该只有一个规范的路径.那么在下面的示例中，好的URL模式将是什么?
As far as I can tell each individual resource should have only one canonical path. So in the following example what would good URL patterns be?
以公司的其余表示为例.在此假设示例中，每个公司拥有 0个或多个部门，每个部门拥有 0个或多个员工.
Take for an example a rest representation of Companies. In this hypothetical example, each company owns 0 or more departments and each department owns 0 or more employees.
没有关联公司的部门不存在.
A department can't exist without an associated company.
没有相关部门的员工不存在.
现在，我将找到资源模式的自然表示形式.
Now I'd find the natural representation of the resource patterns to be.
-
/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}
/companiesA collection of companies - Accepts put for a new company. Get for the entire collection./companies/{companyId}An individual company. Accepts GET, PUT and DELETE/companies/{companyId}/departmentsAccepts POST for a new item. (Creates a department within the company.)/companies/{companyId}/departments/{departmentId}//companies/{companyId}/departments/{departmentId}/employees/companies/{companyId}/departments/{departmentId}/employees/{empId}
考虑到每个部分的限制，我觉得如果嵌套得很深，这是有道理的.
Given the constraints, in each of the sections, I feel that this makes sense if a bit deeply nested.
但是，如果我想列出(GET)所有公司的所有员工，就会遇到困难.
However, my difficulty comes if I want to list (GET) all employees across all companies.
此资源模式将最紧密地映射到/employees(所有员工的集合)
The resource pattern for that would most closely map to /employees (The collection of all employees)
这是否意味着我也应该拥有/employees/{empId}，因为如果是这样，那么有两个URI可以获取相同的资源?
Does that mean that I should have /employees/{empId} also because if so then there are two URI's to get the same resource?
或者可能应该将整个架构展平，但这将意味着员工是嵌套的顶级对象.
Or maybe the entire schema should be flattened but that would mean that employees are a nested top-level object.
在基本级别上，/employees/?company={companyId}&department={deptId}返回与最深层嵌套的模式完全相同的员工视图.
At a basic level /employees/?company={companyId}&department={deptId} returns the exact same view of employees as the most deeply nested pattern.
URL模式的最佳实践是什么，其中资源由其他资源拥有，但应可单独查询?
What's the best practice for URL patterns where resources are owned by other resources but should be query-able separately?
推荐答案
您所做的正确.通常，同一资源可以有很多URI-没有规则说您不应该这样做.
What you have done is correct. In general there can be many URIs to the same resource - there are no rules that say you shouldn't do that.
通常，您可能需要直接访问项目或作为其他内容的子集访问-因此您的结构对我来说很有意义.
And generally, you may need to access items directly or as a subset of something else - so your structure makes sense to me.
仅因为在部门下可以访问员工
Just because employees are accessible under department:
company/{companyid}/department/{departmentid}/employees
并不意味着在公司下也无法访问它们:
Doesn't mean they can't be accessible under company too:
company/{companyid}/employees
哪些人将遣返该公司的员工.这取决于您的客户的需求-这就是您应该设计的.
Which would return employees for that company. It depends on what is needed by your consuming client - that is what you should be designing for.
但是我希望所有URL处理程序都使用相同的后备代码来满足请求，以便您不会重复编写代码.
But I would hope that all URLs handlers use the same backing code to satisfy the requests so that you aren't duplicating code.
这篇关于REST嵌套资源的最佳做法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
