处理耗时操作中的 REST API 超时

Question

如何处理 REST API 中耗时操作的超时。假设我们有以下场景作为示例：

1. 客户端服务通过 REST API 发送插入资源的请求。
2. 超时已过。客户端认为插入失败。
3. REST API 继续工作并完成插入。
4. 客户端不通知资源插入，状态为“失败”。

我可以认为我是一个带有消息代理的解决方案，可以将订单发送到队列并等待它们解决。

还有其他解决方法吗？

编辑 1：

• POST-PUT 模式已在此线程中建议。
• 消息代理（增加系统的复杂性）
• 回调或网络钩子。在请求中传递一个返回 url，服务器 API 可以调用该返回 url，让客户端知道工作已完成。

Answer 1

HTTP 提供了一组用于调用某些方法的属性。这些主要是safetiness，idempotency和cacheability。虽然第一个保证客户端不会修改任何数据，但第二个承诺是否可以重新发出关于连接问题的请求，并且客户端不知道初始请求是否成功，只有响应在中途丢失. PUT即确实提供了这样的属性，即

POST“插入”某些数据的简单请求不具有任何这些属性。接收POST请求的服务器根据自己的语义进一步处理有效载荷。客户端事先不知道是否会创建资源，或者服务器是否只是忽略请求。如果服务器创建了资源，服务器将通过Location指向客户端可以从中检索信息的实际位置的 HTTP 响应标头通知客户端。

PUT通常仅用于“更新”资源，但根据规范，它也可用于创建尚不存在的新资源。与POST成功创建资源一样，PUT响应应包含这样的LocationHTTP 响应标头，以通知客户端资源已创建。

该POST-PUT-创作图案关闭的第一点火分离URI从所述表示的持久性实际的创建POST，直到接收到包含响应请求到服务器Location的HTTP响应报头中。此标头用于PUT请求以实际将有效负载发送到服务器。由于PUT是幂等的，服务器可以简单地重新发出请求，直到它收到来自服务器的有效响应。

在向POST服务器发送初始请求时，客户端无法确定请求是否到达服务器并且只有响应丢失，或者初始请求没有到达服务器。由于请求仅用于创建新的 URI（还没有任何内容），客户端可能会简单地重新发出请求，在最坏的情况下，只需创建一个不指向任何内容的新 URI。服务器可能有一个清理例程，在一段时间后释放未使用的 URI。

一旦客户端接收到 URI，它就可以简单PUT地将数据可靠地发送到服务器。只要客户端没有收到有效的响应，它就可以一遍又一遍地重新发出请求，直到收到响应。

因此，我认为不需要使用使用代理和队列的面向消息的中间件 (MOM) 来保证可靠的消息传递。