在响应HTTP GET时返回202"Accepted"是错误的吗？

Question

我有一组资源,其表示被懒惰地创建.构建这些表示的计算可能需要几毫秒到几个小时,具体取决于服务器负载,特定资源和月亮的相位.

收到的第一个GET请求开始在服务器上进行计算.如果计算在几秒钟内完成,则返回计算的表示.否则,返回202"已接受"状态代码,客户端必须轮询资源,直到最终表示可用.

出现这种情况的原因如下:如果结果在几秒钟内可用,则需要尽快检索; 否则,当它变得可用时并不重要.

由于内存有限和请求量很大,NIO和长轮询都不是一个选项(即我无法保持足够的连接打开,甚至我甚至无法将所有请求都放在内存中;一次"几秒钟"已经过去了,我坚持多余的要求).同样,客户端限制使得它们无法处理完成回调.最后,请注意我对创建一个POST的"工厂"资源不感兴趣,因为额外的往返意味着我们的分段实时约束超出了预期(此外,它是额外的复杂性;此外,这是一种资源,受益于缓存).

我想在返回202"接受"状态代码以响应GET请求方面存在一些争议,因为我在实践中从未见过它,并且它最直观的用法是回应不安全的方法,但我从来没有发现任何特别令人沮丧的事情.而且,我不保持安全和幂等性吗？

那么,人们对这种方法有何看法？

编辑:我应该提到这是一个所谓的商业网络API - 不适用于浏览器.

Answer 1

如果它是一个定义明确的文档API,202听起来恰好适合发生的事情.

如果是公共互联网,我会担心客户端的兼容性.我见过这么多if (status == 200)硬编码......在那种情况下,我会回复一个200.

此外,RFC没有表明使用202作为GET请求是错误的,而它在其他代码描述中明确区分(例如200).

该请求已被接受处理,但处理尚未完成.

Answer 2

我们为最近的应用程序,客户端(自定义应用程序,而不是浏览器)执行了此操作,对查询进行POST,服务器将返回202,其中包含要发布的"作业"的URI - 客户端将使用该URI轮询结果 - 这似乎很好地适应了正在做的事情.

这里最重要的是记录您的服务/ API的工作方式,以及202的响应意味着什么.

Answer 3

根据我的记忆 - GET应该在不修改服务器的情况下返回资源.也许会记录活动或者你有什么,但请求应该可以重新运行,结果相同.

另一方面,POST是一个更改服务器上某些状态的请求.插入记录,删除记录,运行作业等.202适用于返回但未完成的POST,但不是真正的GET请求.

这一切都非常清教徒,并且在野外没有很好的实践,所以你可能通过返回202可以安全.GET应该返回200.如果结束,POST可以返回200或者如果没有完成则返回202.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html