用例: 我正在设计一个更新 API，外部客户端可以在其中传递资源信息(JSON 格式)以保留。整个资源以较小资源的形式持久保存到多个下游(并行)。因此，如果任何一个下游出现故障，我计划返回 5XX http 响应代码以确保客户端重试。但同时要确保客户端知道资源的哪一部分是成功的。
我查看了关于 HTTP 响应代码 207 和 202 的其他类似问题(Q1、Q2)，但它们不适用于我的用例，因为这不是批处理请求，完整资源可以是为外部客户分成更小的资源。根据我的理解，202 适用于我们能够接受请求并仍在处理的异步处理场景，而在我的情况下，我想确保客户端知道请求失败并且他应该重试。
正在考虑的方法 我计划将 HTTP 响应代码返回为 5XX，但同时会将资源的一部分(JSON 格式)添加到成功的响应中。
我想知道上述方法是否被行业标准接受，是否有人解决了此类用例。
最佳答案
老实说，您已经谈到了子资源、部分成功以及能够重试失败的资源。如果您再采取一个步骤:将请求拆分为多个请求，所有这些功能都可以在 HTTP 中完美使用，并且工作得非常好。
关于rest - API响应部分失败并要求客户端重试的行业实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53591726/