我有一组资源，其表示被懒惰地创建。构建这些表示的计算可能需要几毫秒到几个小时，具体取决于服务器负载，特定资源和月相。
为资源收到的第一个GET请求开始在服务器上进行计算。如果计算在几秒钟内完成，则返回计算的表示。否则，返回202“已接受”状态代码，客户端必须轮询资源，直到最终表示可用。
此行为的原因如下：如果结果在几秒钟内可用，则需要尽快检索;否则，当它变得可用时并不重要。
由于内存有限和请求数量庞大，NIO和长轮询都不是一个选项（即我无法保持足够的连接打开，甚至我也无法满足所有内存中的请求;一旦“几秒钟”过去，我会坚持多余的请求）。同样，客户端限制使得它们无法处理完成回调。最后，请注意我对创建一个POST的“工厂”资源不感兴趣，因为额外的往返意味着我们失败的分段实时约束超过了期望（此外，它是额外的复杂性;此外，这是一个资源，将受益于缓存）。
我想在返回202“接受”状态代码以响应GET请求方面存在一些争议，因为我在实践中从未见过它，并且它最直观的用法是回应不安全的方法，但我从来没有发现任何特别令人沮丧的东西。而且，我不是在保持安全和幂等性吗？
那么，人们对这种方法有何看法？
编辑：我应该提到这是针对所谓的商业网络API - 而不是针对浏览器。
答案 0 :(得分：59)
如果它是一个定义明确的文档API，那么202听起来完全正确的发生了什么。
如果是公共互联网，我会担心客户端兼容性。我见过很多if (status == 200)硬编码....在这种情况下，我会返回200。
此外，RFC没有表明使用202作为GET请求是错误的，而它在其他代码描述中明确区分（例如200）。
请求已被接受处理，但处理尚未完成。
答案 1 :(得分：11)
我们为最近的应用程序，客户端（自定义应用程序，而不是浏览器）执行了此操作POST查询并且服务器将返回202，其中包含要发布的“作业”的URI - 客户端将使用该URI对结果进行民意调查 - 这似乎与正在进行的工作非常吻合。
最重要的是，无论如何要记录您的服务/ API的工作方式，以及202的响应意味着什么。
答案 2 :(得分：9)
据我所知 - GET应该在不修改服务器的情况下返回资源。也许会记录活动或者你有什么，但请求应该可以重新运行，结果相同。
另一方面，POST是一个更改服务器上某些状态的请求。插入记录，删除记录，运行作业等。 202适用于返回但未完成的POST，但不是真正的GET请求。
这一切都非常清教徒，并且在野外没有很好的练习，所以你可以通过返回202来保证安全.GET应该返回200.如果结束，POST可以返回200或者如果没有完成则返回202.
答案 3 :(得分：0)
如果资源应该具有由ID明确指定的实体的表示形式（而不是问题中所描述的“工厂”资源），我建议保留GET方法和，在由于懒惰创建或任何其他临时情况而导致实体/表示不可用的情况下，请使用更合适的503 Service Unavailable响应代码，该代码实际上是针对此类情况设计的。
在HTTP本身的RFC中（请验证503响应代码的说明）以及许多其他资源中可以找到相应的理由。
请与HTTP status code for temporarily unavailable pages进行比较。尽管该问题涉及不同的用例，但实际上与HTTP的完全相同的功能有关。