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

Question

假设我有一个代表一组数据的资源 parent。像这样的 RESTful URL 结构应该非常简单:

• GET/api/parents - 返回所有 parent 的集合
• 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 的 child 的集合
• POST/api/parents/1/children - 将新 child 添加到 parent 1 的集合中

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

• 获取、放置或删除/api/parents/44/children/6
• 获取、放置或删除/api/parents/children/6

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

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

Answer 1

@danludwig

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

• 获取“/api/parents/children/6”给我们子资源
• GET 到“/api/parents/children”这里发生了什么？ 404？
• GET 到“/api/parents”给我们所有的 parent
• GET 到“/api”(希望是主页(或索引)文档)以及指向其他从属资源的链接。

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