http - 确定 Web 应用程序中的同步与异步

Question

问题:

有人告诉我，最佳实践指出，长时间运行的 HTTP Web 请求应该转换为具有轮询完成机制的较短的异步请求。

为什么？

重要区别:

我正在开发网络服务 API。它不是要由浏览器调用(这会卡在负载上)，而是要由富客户端(无论如何异步调用远程服务)和脚本(可以执行相同的异步技巧)调用

动机:

我想知道，因为我正在尝试决定何时应将请求设为异步，截止点是什么？我正在开发一个基于 Web 的 API，该 API 的请求需要花费 0.001 秒到 400 秒(以及介于两者之间的任何时间)，具体取决于请求(不是参数，而是他们调用的实际方法)。

我可以让所有事情都异步(除了命令完成的轮询)，但这会使 API 客户端完成的工作复杂化(即从请求中获取结果、轮询完成等)

据我所知，我还可以使所有内容同步，因为两种方式都完成了相同数量的工作，所以看起来负载会相似。

此外，我使用的所有 Web 服务似乎都遵循混合模型，因此它们必须以某种方式做出决定。

我能真正回答这个问题的唯一方法是知道为什么存在这种最佳实践。

Answer 1

异步 ​​API 不会阻塞。每个同步调用都会等待并阻塞您的结果返回。这只是一个 sleep 线程和浪费的计算。

如果您需要发生某些事情，请发送异步请求并在请求返回时进行进一步的计算。这意味着您的线程处于空闲状态并且可以接手其他工作。

异步请求是扩展到数千个并发用户的方式。

but that complicates the work done by API clients

这只是 API 设计的问题。通常，您可以使用回调来调用 Web API 来处理此问题。不需要轮询。

WebService.Call("someMethod" (data) -> {
   // do something when data returns.
});