哪个 URL 应该用于子资源的 GET、PUT 和 DELETE？

Question

假设我有一个资源parent，它代表一组数据。类似这样的宁静 URL 结构应该非常简单：

• GET /api/parents - 返回所有父母的集合
• GET /api/parents/1 - 返回 id = 1 的父级
• POST /api/parents - 向集合添加新的父项
• PUT /api/parents/1 - 更新 id = 1 的父项中的数据
• DELETE /api/parents/1 - 删除 id = 1 的父级

现在说每个parent 都由child 资源的集合组成。子资源 id 是否应该被视为具有全局或本地范围？我相信给出了以下 2 个 URL：

• GET /api/parents/1/children - 返回父级 1 的子级集合
• POST /api/parents/1/children - 将新孩子添加到父 1 的集合中

但是 GET、PUT 和 DELETE 呢？以下哪项是合适的？

• GET、PUT 或 DELETE /api/parents/44/children/6
• GET、PUT 或 DELETE /api/parents/children/6

这似乎归结为 child 资源 ID 的唯一性范围。 ID 是否仅在父聚合中唯一？还是在所有父母的所有孩子中都是独一无二的？一个比另一个更正确，还是取决于相关资源的 id 唯一性范围？

如果示例 1 比示例 2 更合适，并且 id = 44 的父代没有 id = 6 的子代（比如子代 id = 6 属于 id = 9 的父代），应该返回什么 HTTP 响应？

Answer 1

@danludwig

我认为它实际上并不重要，因为 URI 只是资源标识符，所有这些用户友好的层次结构只对人类很重要......但无论哪种情况，我都会问关于这个“/api/parents”的问题/children/6"，让我们分解一下：

• GET to "/api/parents/children/6" 为我们提供子资源
• GET 到“/api/parents/children”这里发生了什么？ 404？
• GET to "/api/parents" 给我们所有的父母
• GET 到“/api”希望主页（或索引）文档，其中包含指向其他从属资源的链接。

我认为在构建分层 URI 时这是一个很好的测试。只需确保每个段都绑定到特定资源并且不返回 404。

Answer 2

ID 是否仅在父聚合中唯一？还是在所有父母的所有孩子中都是独一无二的？

这取决于孩子是唯一一个父母的孩子的可能性。如果是这种情况，那么本地范围的 ID 是可能的。

另一方面，如果一个子节点可以是多个父节点的子节点，则需要全局范围 ID。

当然可以询问具有全局 ID 的子代是否只能存在于父代的“下方”，或者这样的子代是否可以通过不包含父代的 URL 来寻址。

Answer 3

GET, PUT or DELETE /api/parents/44/children/6 URL 在我看来是因为它指示了父资源和子资源之间的关系。

唯一的问题是您需要知道父 ID 才能使用子资源。

另一种方法是一起删除 URL 的“父”部分：GET, PUT or DELETE /api/children/6，并在子资源中包含一个“链接”属性或元素，为其父资源提供 URL。

<child>
   <id>6</id>
   <link rel="parent" href="/api/parents/1" />
   ...
</child>