REST请求的方法,执行时间长？

我们正在构建一个REST服务,大约需要5分钟才能执行.它只会被内部应用程序每天调用几次.是否存在使用REST(即:HTTP)请求需要5分钟才能完成的问题？

我们不得不担心超时吗？我们应该在服务器上的单独线程中启动请求并让客户端轮询状态吗？

这是一种方法.

创建一个执行ProcessXYZ的新请求

POST /ProcessXYZRequests

201-Created
Location: /ProcessXYZRequest/987

如果要查看请求的当前状态:

GET /ProcessXYZRequest/987


  In progress
  

请求完成后,您会看到类似的内容

GET /ProcessXYZRequest/987


  Completed
  

使用这种方法,您可以轻松想象以下请求会给出什么

GET  /ProcessXYZRequests/Pending
GET  /ProcessXYZRequests/Completed
GET  /ProcessXYZRequests/Failed
GET  /ProcessXYZRequests/Today

正如Brian Agnew指出的那样,如果可以控制超时设置,5分钟是完全可管理的,如果有点浪费资源.否则,必须至少发出两个请求:第一个是使结果生成过程滚动,第二个(第三个,第四个,等等,如果结果需要比编译预期的更长)来轮询结果.

Brian Agnew和Darrel Miller都提出了两种(+)步骤方法的类似方法:将请求发送到工厂端点,在服务器上启动作业,然后从返回的结果端点获取结果.

虽然上面是一个非常常见的解决方案,并且确实遵守REST约束的字母,但它却非常像RPC.也就是说,不是说"为我提供此资源的表示",而是说"运行此作业 "(RPC),然后"向我提供运行作业的结果所代表的资源"(REST).编辑:我在这里讲得非常松散.要明确的是,这些都没有明确地违反REST约束,但它非常类似于在REST服装中修饰非RESTful方法,在此过程中失去其好处(例如缓存,幂等性).

因此,我宁愿建议当客户端首次尝试获取资源时,服务器应该响应202"已接受"(http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10. 2.3),也许在响应实体的某处"在5分钟内回过头来".此后,客户端可以轮询相同的端点以获取结果(如果可用)(否则返回另一个202,并稍后再次尝试).

这种方法的一些额外好处是不会不必要地创建一次性资源(例如作业),不需要查询两个单独的端点(工厂和结果),同样第二个端点也不需要通过解析来自首先,这样更简单.此外,结果可以"免费"(代码方式)缓存.根据结果​​在某种意义上为您的问题域"有效"的时间长度,在结果标头中设置缓存过期时间.

我希望我可以称之为"资源导向"方法的教科书示例,但是,或许具有讽刺意味的是,"RESTful Web服务"的第8章提出了两种端点的工厂方法.去搞清楚.

假设您可以使用您选择的任何框架配置HTTP超时,那么您可以通过GET请求并暂停5分钟.

然而,通过POST启动执行可能更灵活,获得收据(数字/ id无论如何),然后使用5分钟后执行GET(并且可能重试,因为您的程序不会花费5分钟每次).如果请求仍在进行中,则返回一个适当的HTTP错误代码(404,但是对于带有不存在的收据的GET,您会返回什么？),或者返回结果(如果可用).