为什么在REST API中使用回调

本文关键字：回调 API REST 为什么 | 更新日期: 2023-09-27 18:02:36

给定一个带有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分钟)。-然而，我忍不住觉得我错过了什么

为什么在REST API中使用回调

嗯，第一种方法对于不需要在服务器端扩展的small(er) operations来说是很好的。一个非常粗略的例子是这样的:

public Response SomeApiMethod(int a, int b)
{
    return a + b;
}

这显然是你不能很好地扩展的东西，也是一个非常基本的操作，我会把它放在你的第一种方法中。

现在，另一方面，如果你提供一些功能，需要做一些really heavy lifting上的东西，像一个巨大的数据库，只是可能需要永远，那么你最好与Callback approach。复杂的操作往往比简单得多的操作产生更多的错误，这可以在服务器上以不同的方式处理。就像在回调过程的一部分事务中出现问题一样，服务器可以简单地重新启动整个进程，并仍然通知用户结果。

关于你的第二种方法，我想提一下:

我假设你会使用ASP.NET为您的API，我到目前为止没有ASP。. NET专家，但我很确定你不能只是触发长时间运行的Task的请求，已经返回了一个响应，因为他们迟早会得到recycled。

然而，你可以做的是使用某种MessageQueue(如MSMQ, RabbitMQ…)，它可以接收关于你的任务的消息，然后可以很容易地由灵活的客户端处理。如果你需要扩展你的API来处理更多的用户，那么你只需要抛出更多的客户端来监听你的Queue的新消息，你基本上就完成了。

我可以看到更多的用法:

1)非。net客户端可以很容易地使用第二种方法

2)你想在不同的URL上处理回调(支付系统API的常见做法)

相关文章：