我有一个RESTful API，供其他内部应用程序使用，它发布更新。
问题是出现了一些意外的峰值，在此期间，请求可能需要超过60秒的时间（负载平衡器定义的限制，我无法更改）才能响应，这导致504 Gateway Timeout错误。
后一个应用程序收到此类响应时，它将在10分钟左右后重试该请求。
这导致一些请求被处理两次，因为第一个请求成功，但是耗时超过60秒。
因此，我决定在请求中使用Idempotency Keys来避免此问题。问题是我不知道在这种情况下应该返回什么。
我应该坚持使用200 OK吗？我应该返回一些4xx代码吗？
答案 0 :(得分：1)
我想说这在很大程度上取决于您是否出错。但是我会说确切的响应代码更多是一个品味问题，而不是最佳实践。但是由于我猜您正在拒绝重复的请求，因此您想报告一个错误代码，例如409 Conflict：
表示由于冲突而无法处理该请求 在资源的当前状态下，例如 多个同时更新。
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_errors
只要满足请求就会导致资源冲突。不支持层叠删除的情况下，重复条目和删除根对象就是几个例子。
答案 1 :(得分：1)
可能有用的参考是RFC 5789，它描述了PATCH方法。显然，您没有做补丁，但是错误处理是类似的。
例如，如果您发送的是JSON Patch document，则可以通过包含一个test operation来检查幂等行为，以检查资源是否处于预期的初始状态。操作完成后，该检查可能会失败。在这种情况下，error handling部分会将您的注意力吸引到RFC 5789上-第2.2节概述了许多不同的可能情况。
另一个灵感来源是查看描述条件请求的RFC 7232。 If-Match的部分包括以下内容：
如果收到的If-Match条件评估为false，则原始服务器不得执行请求的方法；相反，如果原始服务器已验证请求了状态更改并且已经存在最终状态，则原始服务器必须使用以下两种方式之一响应：a）412（失败的前提条件）状态代码或b）2xx（成功）状态代码之一。反映在目标资源的当前状态中（即，用户代理请求的更改已经成功，但是用户代理可能不知道它，可能是因为先前的响应丢失了，或者其他人进行了兼容的更改）用户代理）。
据此推断，如果您可以确定工作已经成功完成，则200完全可以接受。