用于克隆资源的 REST API 设计
REST API design for cloning a resource
我正在使用 swagger 编写 YAML 文档来设计 RESTful API 克隆资源的方法。我有几个选择，但不知道哪个最好。请问有人可以指教吗？
选项：
- 放弃克隆资源对象的责任给消费者（消费者为新对象的属性赋值，然后创建新对象），该过程将需要包含对 API 的两个请求：一个针对源对象资源的 GET，然后一个 POST 到该资源以创建新资源。 感觉消费者责任太大了.
- 使用提供 COPY 方法的 WebDAV HTTP 扩展 (see here)。看起来这正是我想要的克隆。 不过，我想尽可能坚持标准方法
- POSTing to /{resource}?resourceIdToClone={id} 其中 resourceIdToClone 是一个可选参数。这将与我已经拥有的用于创建资源的 API 路径冲突，我在其中向 POST 正文添加了一个架构。 这意味着使用 POST 到 /{resource}/ 来创建和克隆，这会违反 SRP。
- 添加名为 'CloneableResource' 的新资源并对 /CloneableResource/{resource_type}/{resource_source_id} 执行 POST。 以克隆绵羊为例，您可以从 POST 到 /CloneableResource/Sheep/10。这样，就可以坚持使用标准的 HTTP 方法，不会与任何其他资源路径发生冲突（或违反 SRP）。但是，我会向域中添加一个新的且可能是多余的类型。我也想不出消费者想要对该资源执行 POST 以外的任何操作的场景，所以它 对我来说似乎是一种代码味道 。
- 针对 /resource/{id}?method=clone 的 GET。这里的优点之一是不需要额外的资源，它可以通过一个简单的可选查询字符串参数来确定。我知道这里的风险之一是，如果 URL 在网页中，则使用 GET 方法提供 post 或删除功能可能很危险，因为它可能会被搜索抓取引擎。
感谢您的帮助！
如果您想复制资源，那么，复制是一个显而易见的选择。
（是的，最好从 RFC 4918 中提取 COPY 和 MOVE 的定义，以便从 WebDAV 中解开它们）。
这些选项中的大多数都是非常好的选择。很多最终只是你的风格选择。以下是我对每个选项的评论。
将克隆资源对象的责任交给消费者
总的来说，我对这个解决方案真的没有问题。这个选项对于用户理解和实施来说是非常直接的。这可能比提出一些您的用户必须学习如何使用的专有克隆功能要好。
使用提供 COPY 方法的 WebDAV HTTP 扩展
我也喜欢坚持标准方法。我不会用 COPY，但如果你用了我也不会感到震惊。
POSTing to /{resource}?resourceIdToClone={id}
这是一个非常好的解决方案。从 REST 的角度来看，您与 API 的其余部分并没有真正的冲突。带有查询参数的 URI 与没有查询参数的 URI 标识不同的资源。查询参数是一种 URI 特性，用于标识您无法分层引用的资源。但是，由于大多数 REST 框架的工作方式，可能很难在您的代码中将它们分开。您可以执行与此类似的操作，但使用 /{resource}/clone 等分层 URI 除外。您可以 POST 到此 URI 并在正文中传递 resource_source_id。
添加名为 'CloneableResource' 的新资源并对 /CloneableResource/{resource_type}/{[=57= 执行 POST ]}
从 REST 的角度来看，这种方法没有任何问题，但我认为添加新类型既不必要又会使 API 混乱。但是，我不同意您的直觉，拥有只有 POST 操作的资源可能会有问题。它发生了。在现实世界中，并非所有内容都适合 GET、PUT 或 DELETE。
A GET against /resource/{id}?method=clone
这是我不能容忍的 5 个选项中的唯一选项。从你的描述看来你已经明白为什么这是一个坏主意，所以我不确定你为什么要考虑它。但是，要使这个成为一个好的解决方案，您所要做的就是将 GET 更改为 POST。然后它变得与#3 解决方案非常相似。 URI 也可以是分层的，而不是使用查询参数。 POST /resource/{id}/clone 也可以。
希望对您有所帮助。祝你的决定好运。
受项目要求和团队成员偏好范围的影响，选项 1 在现阶段最适合我们。
- 符合标准 HTTP 方法将简化和阐明我的 API
- 克隆资源将采用单一、一致的方法。这超过了我将克隆工作指定给消费者的问题。
我正在使用 swagger 编写 YAML 文档来设计 RESTful API 克隆资源的方法。我有几个选择，但不知道哪个最好。请问有人可以指教吗？
选项：
- 放弃克隆资源对象的责任给消费者（消费者为新对象的属性赋值，然后创建新对象），该过程将需要包含对 API 的两个请求：一个针对源对象资源的 GET，然后一个 POST 到该资源以创建新资源。 感觉消费者责任太大了.
- 使用提供 COPY 方法的 WebDAV HTTP 扩展 (see here)。看起来这正是我想要的克隆。 不过，我想尽可能坚持标准方法
- POSTing to /{resource}?resourceIdToClone={id} 其中 resourceIdToClone 是一个可选参数。这将与我已经拥有的用于创建资源的 API 路径冲突，我在其中向 POST 正文添加了一个架构。 这意味着使用 POST 到 /{resource}/ 来创建和克隆，这会违反 SRP。
- 添加名为 'CloneableResource' 的新资源并对 /CloneableResource/{resource_type}/{resource_source_id} 执行 POST。 以克隆绵羊为例，您可以从 POST 到 /CloneableResource/Sheep/10。这样，就可以坚持使用标准的 HTTP 方法，不会与任何其他资源路径发生冲突（或违反 SRP）。但是，我会向域中添加一个新的且可能是多余的类型。我也想不出消费者想要对该资源执行 POST 以外的任何操作的场景，所以它 对我来说似乎是一种代码味道 。
- 针对 /resource/{id}?method=clone 的 GET。这里的优点之一是不需要额外的资源，它可以通过一个简单的可选查询字符串参数来确定。我知道这里的风险之一是，如果 URL 在网页中，则使用 GET 方法提供 post 或删除功能可能很危险，因为它可能会被搜索抓取引擎。
感谢您的帮助！
如果您想复制资源，那么，复制是一个显而易见的选择。
（是的，最好从 RFC 4918 中提取 COPY 和 MOVE 的定义，以便从 WebDAV 中解开它们）。
这些选项中的大多数都是非常好的选择。很多最终只是你的风格选择。以下是我对每个选项的评论。
将克隆资源对象的责任交给消费者
总的来说，我对这个解决方案真的没有问题。这个选项对于用户理解和实施来说是非常直接的。这可能比提出一些您的用户必须学习如何使用的专有克隆功能要好。使用提供 COPY 方法的 WebDAV HTTP 扩展
我也喜欢坚持标准方法。我不会用COPY，但如果你用了我也不会感到震惊。POSTing to /{resource}?resourceIdToClone={id}
这是一个非常好的解决方案。从 REST 的角度来看，您与 API 的其余部分并没有真正的冲突。带有查询参数的 URI 与没有查询参数的 URI 标识不同的资源。查询参数是一种 URI 特性，用于标识您无法分层引用的资源。但是，由于大多数 REST 框架的工作方式，可能很难在您的代码中将它们分开。您可以执行与此类似的操作，但使用/{resource}/clone等分层 URI 除外。您可以 POST 到此 URI 并在正文中传递resource_source_id。添加名为 'CloneableResource' 的新资源并对 /CloneableResource/{resource_type}/{[=57= 执行 POST ]}
从 REST 的角度来看，这种方法没有任何问题，但我认为添加新类型既不必要又会使 API 混乱。但是，我不同意您的直觉，拥有只有 POST 操作的资源可能会有问题。它发生了。在现实世界中，并非所有内容都适合 GET、PUT 或 DELETE。A GET against /resource/{id}?method=clone
这是我不能容忍的 5 个选项中的唯一选项。从你的描述看来你已经明白为什么这是一个坏主意，所以我不确定你为什么要考虑它。但是，要使这个成为一个好的解决方案，您所要做的就是将 GET 更改为 POST。然后它变得与#3 解决方案非常相似。 URI 也可以是分层的，而不是使用查询参数。POST /resource/{id}/clone也可以。
希望对您有所帮助。祝你的决定好运。
受项目要求和团队成员偏好范围的影响，选项 1 在现阶段最适合我们。
- 符合标准 HTTP 方法将简化和阐明我的 API
- 克隆资源将采用单一、一致的方法。这超过了我将克隆工作指定给消费者的问题。