查找嵌套资源的实践

Question

假设我有一个REST资源，比如：

/Company/{companyId}/Department/{departmentId}/Employees/{employeeId}

和实体类，其中CompanyEntity具有列表 和DepartmentEntity具有列表 。所有ID都是唯一的。

现在有人打电话来了

获取/company/{companyId}/department/{departmentId}/employees/{employeeId}

在Spring Data JPA/Hibernate中找到具有{employeeId}的员工的好方法是什么？

>

道：

赞成：仅1个查询

反：companyId和departmentId未使用。它们甚至可以是随机的。这更像是GET/employee/{id}，但我希望保留与company和Department的嵌套资源。

我还想访问company object以检查询问的人是否与员工在同一公司。

对于（DepartmentEntity部门：company.getDepartments（））{

 if(department.getId() == departmentId) {
   for(EmployeeEntity employee : department.getEmployees()) {
     if(employee.getId() == employeeId)
     return employee;
   }
 }

}

赞成：考虑companyId和departementId

Answer 1

只是通读一下问题和评论，几点：

>

更广泛地接受JB Nizet的建议，我认为其想法是使用可用的最直接的查找，然后进行验证。验证可以保护数据免受未经授权的访问，还可以确保关系查询语义有效。即如果员工记录不在指定的部门,用户不会期望返回该员工记录；因此（在实现中，不一定在API中）提供一种简单的方法，为员工获取部门，为部门获取公司，这样您就可以执行这些验证了。或者，每个容器都可以有一个包含ID的散列集合，因此您可以轻松地确定给定的员工ID是否在department.Employees集合中，以及Company.Departments中的department是否也在其中。

拥有这样的嵌套集合并不稀奇，而且通常很有帮助。关系endpoint是此API设计模式的一个名称。但是我同意Oliver Gierke的观点，您应该为用户提供一个直接到达已知实体的路径。将此因素纳入设计的不同方法：

• 您可以保留嵌套资源，并添加规范的/departments和/employees集合。在从嵌套资源返回的结果中，可以包含一个规范链接，如模式所示。因此，get/companies/123/departments/456/employees/789可以返回一个employee的表示形式，以及一个Canonic链接（在标题或正文中，取决于您的有线格式）到/employees/789，客户机可以使用该链接对employee记录进行后续访问。
• 更进一步，您可以决定只支持一个嵌套级别。因此get/companies/{companyId}/departments返回到公司内各部门的超链接集合；其中每个超链接都指向规范URL,例如/departments/456。不需要进一步的嵌套级别，因为员工和您需要了解的有关部门的其他所有信息都可以通过规范资源获得。