我有一组资源,其表示被懒惰地创建.构建这些表示的计算可能需要几毫秒到几个小时,具体取决于服务器负载,特定资源和月亮的相位.
收到的第一个GET请求开始在服务器上进行计算.如果计算在几秒钟内完成,则返回计算的表示.否则,返回202"已接受"状态代码,客户端必须轮询资源,直到最终表示可用.
出现这种情况的原因如下:如果结果在几秒钟内可用,则需要尽快检索; 否则,当它变得可用时并不重要.
由于内存有限和请求量很大,NIO和长轮询都不是一个选项(即我无法保持足够的连接打开,甚至我甚至无法将所有请求都放在内存中;一次"几秒钟"已经过去了,我坚持多余的要求).同样,客户端限制使得它们无法处理完成回调.最后,请注意我对创建一个POST的"工厂"资源不感兴趣,因为额外的往返意味着我们的分段实时约束超出了预期(此外,它是额外的复杂性;此外,这是一种资源,受益于缓存).
我想在返回202"接受"状态代码以响应GET请求方面存在一些争议,因为我在实践中从未见过它,并且它最直观的用法是回应不安全的方法,但我从来没有发现任何特别令人沮丧的事情.而且,我不保持安全和幂等性吗？
那么,人们对这种方法有何看法？
编辑:我应该提到这是一个所谓的商业网络API - 不适用于浏览器.
作为REST服务的一部分,我需要实现搜索调用.基本思想是用户可以发布新搜索,并获取结果:
POST http://localhost/api/search
GET http://localhost/api/search?id=123
但是,我的搜索可能会运行几分钟,并返回部分结果,直到完成为止.也就是说,GET-Request会返回如下内容:
status: running
results: a, b, c.
而下一个GET-Request可能会返回
status: completed
results: a, b, c, d, e.
这与RESTful GET请求的语义相矛盾.多次调用时,请求应始终返回相同的结果.例如,当用户使用高速缓存代理时,可能永远不会将完整结果传递给用户.
问题:有没有办法为部分结果的长时间运行搜索提供真正的RESTful实现？
是否有HTTP状态代码来指示客户端再次执行相同的请求？
我面临的情况是服务器必须"等待"锁定在处理请求时消失.但是当锁消失时,请求可能接近其超时限制.因此,一旦锁定清除,我想指示客户端再次执行相同的请求.
我提出的最好的是到相同位置的HTTP 307,但我担心一些浏览器可能不会购买(重定向循环检测).
首先,我读了一些相关的帖子:
但我仍然认为我应该在这里提出我的问题和想法.REST API中的HTTP状态代码应该是什么？使用GET到QUERY"未准备好,稍后再试"资源？例如,客户端尝试通过对此URL进行HTTP GET来查询将来发生的所有本地新闻(!):http://example.com/news？city = chicago& date = 2099-12-31那么服务器应该回复什么？
这些是我考虑的http状态代码,它们的rfc定义以及为什么我不完全满意:
3xx重定向.注释:不是一个选项,因为没有其他链接可以重定向到.
503服务不可用:由于服务器临时过载或维护,服务器当前无法处理请求.这意味着这是一个暂时的条件,经过一段时间的延迟后会得到缓解.如果已知,则可以在Retry-After报头中指示延迟的长度.注释:需要重试行为,但从语义上讲,情况根本不是服务器的错误,因此所有5xx看起来都很奇怪.
4xx客户端错误.评论:看起来很有希望 见下文.
413请求实体太大:服务器拒绝处理请求,因为请求实体大于服务器愿意或能够处理的请求实体....如果条件是临时的,服务器应该包括一个Retry-After头字段,以指示它是临时的,以及客户端可以再次尝试的时间.注释:需要重试行为,但"实体太大"部分有些误导.
417期望失败:此服务器无法满足Expect请求标头字段(请参阅第14.20节)中给出的期望.注释:所以它应该是由Expect请求标头引起的,不适用于我的情况.
406 Not Acceptable:资源...根据请求中发送的accept头不可接受.注释:所以它是由Accept request-header引起的,不适用于我的情况.
409冲突:由于与资源的当前状态发生冲突,无法完成请求.此代码仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许....响应PUT请求最有可能发生冲突.评论:这个很接近.虽然我的情况不是关于PUT,实际上并不是由冲突造成的.
404 Not Found:服务器未找到与Request-URI匹配的任何内容.评论:从技术上讲,我的网址路径(http://example.com/news)存在,它是导致问题的参数.在这种情况下,返回空集合而不是404,可能更合适.
403 Forbidden:服务器理解请求,但拒绝履行请求.授权无效,请求不应重复.评论:通常这应该用于任何受限制的资源？
400错误请求:由于语法格式错误,服务器无法理解请求.客户端不应该在没有修改的情况下重复请求.评论:在我的案例中并非如此.我的服务器理解请求,它的语法很好,只有意思不好.
2xx成功.评论:如果4xx不起作用,2xx怎么样？见下文.
200好的.评论:很好.那么我应该在响应体中包含什么呢？null或[]或{}或{"date":"2099-12-31","content_list":null}或者......哪一个更直观？另一方面,我更喜欢一种方法,以明确区分未成年人"未来新闻"错误与更常见的"所有查询标准都很好,这一天没有新闻"的情况.
202 Accepted:已接受请求进行处理,但处理尚未完成.该请求最终可能会或可能不会被采取行动.注释:假设我们可以在GET请求中使用202,则可以接受.然后参考200评论.
204 No Content:服务器已完成请求,但不需要返回实体.注释:假设我们可以在GET请求中使用204,则可以接受.只是不知道这是否优于202或200.
更多关于2xx: …
我正在制作一个主要由数据库提供的 HTTP Web API。简单来说，数据库包含用户对象。
这些对象有一个last_online（当用户在线时）和last_checked（我上次检查用户对象时）。
检查用户对象可能需要 3 到 30 秒的时间。当last_checked时间少于10分钟时一切正常；API 调用返回200和用户对象。
但我想当数据超过 10 分钟时重新处理用户对象。显然我不能让我的 API 返回坐在那里等待。
对于（有时）需要从长时间运行的进程返回数据的 HTTP API，正确的方法是什么？