何时使用异步和等待 - 客户端与 webapi [关闭]

Question

我正在使用 ASP.NET Web Api 构建一个规划器，它目前在其中执行一些简单的 CRUD 操作。此 API 的主要目的之一是能够接受来自不同平台（Web 和 android 应用程序客户端）的请求。我的问题是关于 async 和 await 和 web api 的最佳实践（以及什么是有意义的）——我应该在哪里提供异步？在客户端级别还是在 API 级别（服务器）？

我知道 async 和 await 的主要目的之一是为 UI 提供响应能力。而且我知道异步模型主要涵盖 I/O 绑定或 CPU 绑定操作。我猜从这个意义上说，我的进程会受到 I/O 限制。但最佳实践是明智的，API 应该是异步的还是应该保留在客户端中？我的 api 将在 Azure 的应用服务上运行。

以下是我的 API 中的示例“获取”操作（同步代码而非实际代码）：

[Authorize]
[Route("GetUser/{userId}")]
public IHttpActionResult GetUser(int userId)
{
    return Ok(/* method calls are done here... */);
}

我提出的异步示例：

[Authorize]
[Route("GetUser/{userId}")]
public async Task<IHttpActionResult> GetUser(int userId)
{
    return Ok(await /* method calls are done here... */);
}

我正在使用 HttpClient 向 api 发出请求。

我的期望是多个人将使用该客户端。所以我会假设客户端应该是异步的，并且 api 可以保持同步。但同样，我试图弄清楚这里最好的做法是什么（明智的最佳实践）。

Answer 1

既然您已经要求最佳做法，请一直采用异步方式。 当您尝试使其以同步方式工作时，异步只会变得复杂（并给您带来麻烦）。一路异步（用 asp.net core 很容易做到），你会很好。

来源：https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/blob/master/AsyncGuidance.md

（如果 API 操作本质上没有执行任何异步操作，您可以在该 API 上保留异步，但默认为异步。）

Answer 2

因为它是一个网络服务器，所以没有线程负责更新 UI，就像在本地应用程序中一样。所以这并不是真正的考虑因素。

async/await 在 Web 服务器中的主要优点是，当您等待长时间的 I/O 操作时，线程被释放以执行其他任务。如果您的 Web 服务器确实受到重创，例如 100 次点击/秒，并且它正在使用其线程池中的每个线程，那么新的 Web 请求必须等到一个线程被释放才能被处理。

如果您没有受到那么严重的打击和/或您没有相对较长的 I/O 操作，那么您的第一个代码 sn-p 就可以了，您无需深入研究 async/await 的复杂性.但是，在客户端，您应该使用异步来执行这些 Web 服务器调用，因为它们是 I/O 调用并且可能会阻塞 UI 线程。