Question

在异步REST API中创建资源，如果我的服务器响应带有状态指示符的不完整资源而不返回temporary resource，是否有效？

举个例子，我有一个公证服务，将消息添加到区块链中，以便以后证明它们的存在（例如“存在证明”）。

执行需要花费一些时间，因此异步制作是一个好主意。

用户发送一个POST /messages，其中包含有效载荷：

{
    "message" : "Hello SO friends!"
}

然后服务器用正文响应202 Accepted：

{
    "id" : 1999283,
    "message" : "Hello SO friends!",
    "status" : "pending",
    "block" : null,
    "timestamp" : null
}

还有标题Location: /messages/1999283

上面描述的资源是不完整，因为它仍然没有阻止和时间戳，并且具有“待处理”状态。

在服务器等待将其添加到块中时，用户将轮询/messages/1999283并在正文中获得与上面的json相同的200 OK。

几分钟后，用户将再次轮询并获得200 OK以及 complete 资源：

{
    "id" : 1999283,
    "message" : "Hello SO Friends!",
    "status" : "completed",
    "block" : 10029,
    "timestamp" : "20181215T204012Z"
}

Answer 1

我认为您所遵循的方法是正确的。 202 Accepted 状态的核心目的是“请求已被接受，服务器将对其进行处理”。

现在我唯一能看到的问题是直到什么时候？要回答这个问题，我建议您可以添加一些计算，该计算将检查处理类似请求并将其发送给第一响应的平均时间。

{
    "id" : 1999283,
    "message" : "Hello SO friends!",
    "status" : "pending",
    "block" : null,
    "timestamp" : null,
    "estimatedTime" : 30 ////
}

这将具有2个优点：

1）用户将知道处理请求将花费多少时间，并且不会轮询那么多时间，从而节省了服务器上的点击次数。

2），您可以跟踪重复失败的原因，例如，如果同一请求多次失败，则可以根据业务需求增加该请求的优先级。

除此之外，其他过程看起来非常整洁。

Answer 2

另一种看待此问题的方法可能不是临时资源。也许这是状态不完整的常规资源。

如果您认为它是稍后会更改状态的真实资源，则无需考虑使用g。您正在创建的交易“存在”，但尚未处理。

用不完整的资源响应REST API中的异步请求

2 个答案: