对于已处理的 POST 请求，最合适的 HTTP 状态代码是什么？

Question

我有一个 RESTful API，由另一个发布更新的内部应用程序使用。

问题是出现了一些意外的峰值，在这些时间内，请求可能需要超过 60 秒（负载均衡器定义的限制，我无法更改）来响应，这会导致504 Gateway Timeout错误。

当后一个应用程序得到这样的响应时，它会在 10 分钟左右后再次重试请求。

这导致了一些请求被处理了两次，因为第一次请求成功，但是耗时超过 60 秒。

所以我决定在请求中使用幂等键来避免这个问题。问题是我不知道在这种情况下我应该返回什么。

我应该坚持200 OK吗？我应该返回一些4xx代码吗？

Answer 1

我会说这在很大程度上取决于它是否对您来说是错误的。但我想说确切的响应代码更多的是品味问题而不是最佳实践。但是因为我猜你拒绝了重复的请求，所以你想报告一个错误代码，比如409 Conflict：

表示由于资源当前状态的冲突而无法处理请求，例如多个同时更新之间的编辑冲突。

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_errors

每当完成请求会导致资源冲突时。不支持级联删除时的重复条目和删除根对象是几个示例。

https://www.restapitutorial.com/httpstatuscodes.html

Answer 2

RFC 5789 是一个可能有用的参考，它描述了 PATCH 方法。显然，您没有做补丁，但错误处理是类似的。

例如，如果您要发送JSON Patch 文档，那么您可以通过包含检查资源是否处于预期初始状态的测试操作来确保幂等行为。在您的操作之后，该检查可能会失败。在这种情况下，错误处理部分会将您的注意力引向RFC 5789——第 2.2 节概述了许多不同的可能情况。

另一个灵感来源是查看描述条件请求的 RFC 7232。关于If-Match 的部分包括这个宝石：

如果接收到的 If-Match 条件评估为 false，源服务器不得执行请求的方法；相反，如果源服务器已验证正在请求状态更改并且最终状态已完成，则源服务器必须以 a）412（前置条件失败）状态代码或 b）2xx（成功）状态代码之一进行响应反映在目标资源的当前状态中（即，用户代理请求的更改已经成功，但用户代理可能没有意识到这一点，可能是因为先前的响应丢失或其他一些人进行了兼容的更改）用户代理）。

由此看来，如果你能确定工作已经成功完成的话，200是完全可以接受的。