REST 嵌套资源的最佳实践是什么? [英] What are best practices for REST nested resources?

查看:28
本文介绍了REST 嵌套资源的最佳实践是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

据我所知,每个单独的资源应该只有一个规范路径.那么在下面的例子中,好的 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.

没有关联公司,部门就无法存在.

没有关联部门的员工不可能存在.

现在我会找到资源模式的自然表示.

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}
  • /companies A 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}/departments Accepts 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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆