据我所知,每个资源应该只有一个规范路径.因此,在下面的示例中,优秀的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模式的最佳实践是什么,其中资源由其他资源拥有但应该可以单独查询？
更新:请参阅下面的答案,看看我做了什么.
我正在开发一个REST服务,我正在努力遵守Roy Fielding博士的惯例和指导方针.
我将我的服务描述为暴露一组资源的端点.资源由URI标识,并且api客户端可以通过使用HTTP语义来操纵资源(即,不同的HTTP谓词映射到URI上的相应操作).
指南声明这些URI应以分层方式定义,反映对象层次结构.这在资源创建中很有用,因为在后端我们需要数据来执行创建操作.然而,在进一步的操作中,URI中包含的许多信息甚至不会被服务使用,因为通常仅资源Id足以唯一地标识操作目标.
一个例子:考虑一个暴露产品创建和管理的Api.还要考虑产品与品牌相关联.在创建时,执行以下操作是有意义的:HTTP POST/Brand/{brand_id}/Product [包含创建产品所需的输入的正文]
创建返回使用位置标头创建的HTTP 201,该位置标头公开新创建的产品的位置.
在进一步操作时,客户可以通过以下方式访问产品:HTTP PUT/Brand/{brand_id}/Product/{product_id} HTTP DELETE/Brand/{brand_id}/Product/{product_id}等
但是,由于产品ID在产品范围内是通用的,因此可以执行以下操作:/ Product/{product_id}我只保留/ Brand/{brand_id}前缀以用于一致性原因.事实上,该服务忽略了品牌ID.你认为这是一个好的做法,并且为了保持一个明确,明确的ServiceInterface定义是合理的吗？这样做有什么好处,这是一种方法吗？
此外,任何有关URI定义最佳实践的指针都将受到赞赏.
提前致谢