Question

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

我知道异步和等待的主要目的之一是为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

由于它是Web服务器，因此没有像本地应用程序那样负责更新UI的线程。所以这不是一个真正的考虑。

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

如果您没有受到太大的冲击和/或没有相对较长的I / O操作，则您的第一个代码段很好，您无需深入研究异步/等待的复杂性。但是，在客户端，您应该使用async来进行这些Web服务器调用，因为它们是I / O调用，并且可能会阻塞UI线程。

何时使用异步和等待-客户端与Webapi

2 个答案: