应该将哪个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“，让我们分解：

• 获取“/ api / parents / children / 6”为我们提供了儿童资源
• 获取“/ api / parents / children”会发生什么？ 404？
• GET to“/ api / parents”给了我们所有的父母
• 获取“/ api”希望带有指向其他次级资源的主页（或索引）文档。

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

Answer 2

  

ID仅在父聚合中是唯一的吗？或者它在所有父母的所有孩子中都是独一无二的吗？

这取决于孩子是一个且只有一个父母的cild的可能性。如果是这种情况，则可以使用本地范围的ID。

另一方面，如果孩子可能是多个父母的孩子，则需要全球范围的身份证。

当然，可以询问具有全局ID的孩子是否只能存在于父母的“下方”，或者是否可以使用不包含父母的URL来解决这样的孩子。

Answer 3

GET, PUT or DELETE /api/parents/44/children/6网址向我看来，因为它表示父资源和子资源之间的关系。

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

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

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