通过 REST 服务进行批处理

Question

是否有通过 REST 对 POST、PUT、PATCH 动词执行 BATCH 操作的最佳实践？

我遵循的当前范例是在所有 3 个操作的主体中指定 JSON 有效负载：

a) POST 返回创建资源的位置
b) PUT / PATCH 如果更新成功则返回 201

对于批处理操作，我打算在有效负载主体中接受 JSON 对象的集合，但我试图确定要返回给客户端的内容。

处理批次时，某些项目的操作可能会成功，但其他项目的操作可能会失败。

考虑到这一点，我的看法是，最好的办法是返回一个对象集合，指示有效负载中每个项目的成功/失败状态。

但这偏离了我在上面（a）和（b）中概述的范例。

相反，向客户端返回表示批处理操作本身 ID 的标识符是否有意义？

然后，客户端将发出后续 GET 以获取其请求的操作的结果。

这种方法听起来合理吗？如果是这样，如果操作尚未完成，则在后续 GET 上阻止客户端是否有意义，或者始终返回最新状态（即客户端请求处理的每个项目的响应集合）是否有意义。

想法/想法/建议？

由于 REST 是一种架构风格，不一定有明确的“指南”，也没有强制要求如何实现 HTTP 动词的操作，因此显然这里没有正确或错误的答案。

我正在寻找一种优雅、自然且直观的解决方案。

Answer 1

REST 是一种架构风格。

我实现 API 来始终返回更新的结果。因此，在 POST 的情况下，它将返回创建的实体，在 PATCH 和 PUT 的情况下，它将返回更新的实体。

根据批量大小，我要么返回已处理内容的数组，要么返回已处理内容的标识符数组。

如果批处理操作长时间运行，则返回批处理的标识符，但要痛苦地明确该端点与其他端点不同

在获取时返回批处理操作仍在运行时的状态，在完成时返回已更新的记录数组。

最重要的是一致性，无论您选择什么，整个系统始终遵循相同的批量操作方法。