Question

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

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

Answer 1

这是一种方法。

创建执行ProcessXYZ的新请求

POST /ProcessXYZRequests

201-Created
Location: /ProcessXYZRequest/987

如果您想查看请求的当前状态：

GET /ProcessXYZRequest/987

<ProcessXYZRequest Id="987">
  <Status>In progress</Status>
  <Cancel method="DELETE" href="/ProcessXYZRequest/987"/>
</ProcessXYZRequest>

请求完成后，您会看到类似

的内容

GET /ProcessXYZRequest/987

<ProcessXYZRequest>
  <Status>Completed</Status>
  <Results href="/ProcessXYZRequest/Results"/>
</ProcessXYZRequest>

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

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

Answer 2

正如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章提出了双端点工厂方法。去图。

Answer 3

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

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

Answer 4

如果你控制两端，那么你可以做任何你想做的事情。例如。浏览器倾向于使用“连接关闭”标头启动HTTP请求，因此您可以选择较少的选项; - ）

请记住，如果你之间有一些NAT /防火墙，如果它们在一段时间内处于非活动状态，你可能会有一些连接。

我可以建议注册“回调”程序吗？客户端向服务器发出带有“回调端点”的请求，获取“票证”。服务器完成后，它“回调”客户端......或者客户端可以通过票证标识符检查请求的状态。

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

4 个答案: