是否有通过REST为POST，PUT，PATCH动词执行BATCH操作的最佳实践？
我遵循的当前范例是在所有3个操作的主体中指定了json有效负载
a）POST返回创建资源的位置
b）如果更新成功，PUT / PATCH返回201
对于批处理操作，我打算在有效负载主体中接受json对象的集合，但我试图找出返回客户端的内容。 处理批处理时，某些项目的操作可能会成功，但对其他项目可能会失败。
考虑到这一点，我认为最好的办法是返回一组对象，指出每个对象的成功/失败状态。 来自有效载荷的项目。
但这与我上面（a）和（b）中概述的范例不同。
相反，将表示批处理操作本身的ID的标识符返回给客户端是否有意义？
然后，客户端将发出后续GET以获取其请求的操作结果。
这种方法听起来合理吗？如果是这样，如果操作没有完成就阻塞后续GET上的客户端是否有意义或者是否有意义总是返回最新状态，即客户端请求的每个项目的响应集合处理。
思想/思考/建议？
由于REST是一种架构风格，因此没有明确的指南和＃34;和不 强制要求如何实现HTTP动词的动作，显然这里没有正确或错误的答案。
我正在寻找一种优雅，自然和直观的解决方案。
答案 0 :(得分：2)
REST是一种架构风格。
我实现API以始终返回更新内容的结果。所以在POST的情况下它将返回创建的实体，使用PATCH和PUT它将返回更新的实体。
根据批量大小，我会返回已处理内容的数组，或者返回已处理内容的标识符数组。
如果批处理操作长时间运行，则返回批处理的标识符，但要清楚地表明端点与其他端点不同
离。如果您通过发布创建用户 http://somesite.com/users
发送批量请求 http://somesite.com/batch/users
在获取返回时，批处理操作仍处于运行状态时，完全返回已更新的记录数组。
最重要的是一致性，无论您选择什么，在整个系统中始终遵循相同的批处理操作方法。
答案 1 :(得分：2)
从外部看，REST操作应该是原子的。也就是说，如果请求的一部分失败，那么服务器的整个状态应该恢复到预请求状态并返回4xx或5xx响应（因此，例如，请求可以整体重复而不会产生不良影响，如果它第一次失败了）。然而，这与批处理操作本身无关 - 这样的请求可以是任何类型的请求。
批处理操作违反了不同的REST约束，统一接口的约束（由HTTP方法定义，以及它们对指定URL上的资源的操作）。
如果您想进行批量操作，请放弃尝试调用您的API RESTful，因为您已经失去了REST赋予的好处，并且只是骗你自己。
如果您想保留这些好处，请放弃批量操作。