给定具有2个端点的REST API：
http://example.com/api/send?id=someId
客户端：
对该端点的调用是在代码中异步完成的。
服务器端：
收到请求后，将启动一些异步任务。然后，服务器使用
await关键字等待这些异步任务的结果。最后，它返回结果。
http://example.com/api/sendAsync?id=someId&callbackUrl=http://something.com/done
客户端：
对该端点的调用是在代码中异步完成的。
服务器端：
收到请求后，将启动一些异步任务。服务器立即返回带有ID的结果以标识该操作。只要结果可用，服务器就会使用结果和ID调用callbackUrl。
为什么我需要第二种方法？
在我看来，第一种方法同样有效。服务器使用await关键字等待结果的事实使其无阻塞，因为关键字之后的所有内容都被注册为延续。客户端也是非阻塞的，因为它是异步Web请求。
我确实意识到，第二种方法可能会很有用，如果处理请求的时间非常长（+5分钟）。-但是，我不禁觉得自己缺少了一些东西。
好吧，第一种方法很好，small(er) operations因为不需要在服务器端进行横向扩展。一个非常粗糙的例子是这样的：
public Response SomeApiMethod(int a, int b)
{
return a + b;
}
显然，这是您无法很好地扩展的东西，也是我将在您的第一种方法中采用的非常基本的操作。
现在，另一方面，如果您提供某些功能需要really heavy lifting在大型DB之类的东西上做一些事情，而这些功能可能会永远永久使用，那么您最好使用Callback approach。与简单的操作相比，复杂的操作往往会导致更多的错误，而简单的操作可以在服务器上以不同的方式进行处理。就像如果作为回调过程一部分的事务中出现问题时，服务器可以简单地重新启动整个过程，并仍将结果通知用户。
关于您的第二种方法，我想提一提：
我假设您将使用ASP.NET您的API，但到目前为止我还不是ASP.NET专家，但我很确定您不能只是Task在已经返回响应的Request中触发长时间运行的，recycled早晚获得。
但是，您可以做的是使用某种MessageQueue（如MSMQ，RabbitMQ ...），该消息会接收到有关您的任务的消息，然后可以通过大量的客户端轻松地对其进行处理。如果您需要扩展您的API以处理大量用户，则只需添加更多客户端来监听Queue的新消息即可，基本上就可以完成。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句