下游提供无效数据时向客户端发送 Http 状态码

Posted 2023-03-31

【中文标题】下游提供无效数据时向客户端发送 Http 状态码

【英文标题】：Http status code to a client when downstream provides invalid data

【发布时间】：2021-11-10 18:04:23

【问题描述】：

有一种情况是，为了满足 API 消费者的请求，我们正在回调消费者以获取额外的数据，而额外的数据可能是无效的。在这种情况下，我们应该以 400 Bad Request HTTP 状态代码或 500 Internal Server 响应的最佳实践是什么，因为我们收到了有效的请求，但由于错误的状态而无法完成请求？ 提前致谢。

【参考方案1】：

如果请求本身的格式没有问题，但其他一些资源的状态是错误的，我认为有两种可能的方法来考虑这个问题：

如果客户负责“附加数据”，并且这是他们可以修复的东西，409 Conflict 可能是最合适的。 409 有效地表明，如果“附加数据”的不良状态得到修复，客户端发送的请求可能在未来是正确的。 如果“附加数据”是客户几乎无法控制的系统内部部分，我认为5xx-category 错误是最正确的。请求很好，但内部问题导致它失败。客户不在乎它是否涉及不同的系统。事实上，它是一个实现细节。

【讨论】：

感谢Evert的详细回复。这很棒。当服务器理解请求但无法处理包含的指令时，422 Unprocessable Entity 怎么办。第一个选项可以接受这种状态吗？很高兴知道你的意见

将 422 视为“这是有效的 JSON，但缺少一个属性”。所以可以解析请求体，但还是不正确。我写了一篇关于每个状态码的文章，所以我在这里有更多的背景：evertpot.com/http/422-unprocessable-entity

如果客户负责的附加数据缺少属性，最好使用422或409？

如果“缺失的属性”在请求正文中，则为422.. 如果需要修复其他资源，则为409感觉还是最合适的。

谢谢你，埃弗特！

【参考方案2】：

HTTP 错误代码可以根据服务将使用客户端提供的附加数据执行的操作来定义。如果是用于搜索操作，那么您可以将 404 用于未找到的资源或 400 用于格式错误或无效的数据。 5xx 系列本质上非常敏感，这意味着如果返回 5xx，您的客户端可能会定义许多额外的工作流程，例如重试（标准或长），这可能会在处理实时数据时导致麻烦。