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

2018-05-31 10:59:02

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

以公司的其他代表为例。在这个假设的例子中，每个公司拥有 0个或更多的部门，每个部门拥有 0个或更多的员工。

一个部门可以没有关联的公司存在。

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

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

/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}返回与最深嵌套模式完全相同的员工视图。

URL模式的最佳实践是哪些资源由其他资源拥有，但应该单独进行查询？

看到我下面的答案，看看我做了什么。

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

一般而言，您可能需要直接访问项目或将其作为其他项目的子集，因此您的结构对我来说很有意义。

仅仅因为员工可以在部门中访问：

company/{companyid}/department/{departmentid}/employees

这并不意味着他们无法在公司之下进行访问：

company/{companyid}/employees

这将返回该公司的员工。这取决于你的消费客户需要什么 - 这就是你应该设计的。

但我希望所有URL处理程序都使用相同的后备代码来满足请求，以便不重复代码。

我尝试了两种设计策略 - 嵌套和非嵌套端点。我发现：

如果嵌套资源具有主键并且没有其父主键，则嵌套结构需要您获取它，即使系统实际上并不需要它。

嵌套端点通常需要冗余端点。换句话说，您通常会需要附加/员工端点，以便您可以获得跨部门的员工列表。如果你有/员工，那么/公司/部门/员工向你购买什么？

嵌套端点不会很好地发展。例如，您现在可能不需要搜索员工，但以后可能会找到，如果您有嵌套结构，则只能添加另一个终结点。使用非嵌套设计，您只需添加更多参数，这更简单。

有时候资源可能有多种类型的父母。导致多个端点都返回相同的资源。

多余的端点使得文档更难写，并且使api更难学习。

简言之，非嵌套设计似乎允许更灵活和更简单的端点模式。

我已经将我从这个问题所做的一切转移到了更多人可能会看到的答案上。

我所做的是在嵌套端点上创建端点，在非嵌套资源上修改或更改项目的规范端点。

所以在这个例子中（只列出了更改资源的端点）

POST /companies/创建一个新公司返回创建公司的链接。

POST /companies/{companyId}/departments放置/companies/{companyId}/departments时创建新部门返回链接到/departments/{departmentId}

PUT /departments/{departmentId}修改部门

POST /departments/{deparmentId}/employees创建一个新员工返回指向/employees/{employeeId}的链接

所以每个集合都有根级别的资源。然而，建立在所属对象。

链接地址: http://www.djcxy.com/p/7003.html