Question

我正在设置一个Web API，它将通过我们的Intranet为客户端提供服务。为了方便开发人员使用客户端，我正在考虑让Web API遵循将与客户端共享的接口，如下所示。

使用共享接口的目的主要与在编译时客户端开发人员可以检测到Web API的更改有关。此外，客户端可以利用该接口用于将用于与Web API通信的HttpClient实例的包装器。

客户端开发人员希望在整个实施过程中使用async和await，我应该说谁＆＃34; no＆＃34;？

public interface IValueController
{
    Task<string> ReadAsync();
    string ReadSync();
}

[Route("api/v1/[controller]")]
public class ValueController : Controller, IValueController
{
    [HttpGet("async")]
    public Task<string> ReadAsync()
    {
        return Task.FromResult("async!");
    }

    [HttpGet("sync")]
    public string ReadSync()
    {
        return "sync!";
    }
}

我并不是所有对提供同步和异步方法感兴趣的人 - 其中一个方法必须这样做。问题是：将Web API操作定义为异步是否有任何缺点？如果没有，我会全押！

-S

Answer 1

何时使用Async：

异步API调用。
长时间运行数据库查询。
受CPU限制的任务。
当你需要实现并行时。

何时不使用：编写任何快速运行的任务或方法时。

注意：请注意死锁，因为编译器允许您编写并成功编译异步代码，即使不了解它的基本概念。

Answer 2

使用共享接口的目的主要是在编译时对客户端开发人员可以检测到的Web API进行更改。

现在，更常见的是自动生成API描述（例如，Swagger），然后从中自动生成客户端（可以是.NET或其他语言）。这种方法不仅允许多个客户端（例如，一个Swagger客户端是API的HTML文档，完整的示例和直接从网站调用它们的能力），但它也可以为您处理同步/异步转换，而无需任何客户端。那种“异步签名但真的是同步”代码。

也就是说，如果你想同步实现异步方法，没有任何东西可以阻止它。我能想到的唯一问题是，如果你使用的是完整的ASP.NET，那么异步操作就不能是子操作。 ASP.NET Core上不再存在此限制。

ASP.NET Web API：异步操作的任何缺点？

2 个答案: