RESTful 设计：创建子资源的最佳实践答案

【问题标题】：RESTful design: Best practices for child resource creationRESTful 设计：创建子资源的最佳实践
【发布时间】：2017-07-16 11:07:38
【问题描述】：

场景：

我有一些资源 Foo，它有 0..n 个子资源 Bar。

有一个端点——http://resource/foo——它支持GET 获取所有Foo 资源的列表，并支持POST 在父服务器上创建一个新的Foo 实例。

有一个端点-http://resource/foo/:fooId:-支持GET 获取Foo 资源，PATCH 更新Foo 资源，以及DELETE 删除Foo 资源。

有一个端点 - http://resource/foo/:fooId:/bar - 支持 GET 获取给定 Foo 上所有 Bar 资源的列表，以及 POST 在给定的 Bar 上创建一个新实例福。

POST 到 http://resource/foo 应该支持直接创建带有一些 Bar 子代的 Foo，还是应该在初始创建 Foo 之后仅由不同的附加 POSTs 到 http://resource/foo/:fooId:/bar 支持创建子代?

【问题讨论】：

通常情况下，最合乎逻辑的方法是使用像POST /bars 这样的端点。请求正文将是构建 bar 所需的属性的表示，该 bar 将包括相关 foo 的标识符。像/foos/:id/bars 这样的端点更像是一个“快捷方式”或过滤端点，用于提供/bars 集合的过滤版本，通常只支持GET 请求。但是，我所说的都不是硬性规则；更像是好的指导方针。

【解决方案1】：

不幸的是，这些问题没有共同的答案，因为您需要考虑业务领域和您的 API 工作的环境（性能、公共可用性、标准、现有端点的设计方式等）以及大量其他因素.但是，最好从业务角度入手，因为任何代码都旨在解决实际问题。

你可以先问自己以下问题：

或类似的东西：

Bar 在创建Foo 时是可选的吗？

如果您看到它是可选的，则将Bar 作为子资源并独立处理Bar 的集合/实例。只需使用 hal 将 Bar 添加为嵌入资源，这将是非常 RESTful 并使父子关系透明。使资源尽可能简单并尽可能减少耦合是REST api 的一个好策略。

【讨论】：