ASP.NET Web API：异步操作有哪些缺点？

Question

我正在设置一个 Web API，将通过我们的内部网络服务于客户端。为了方便客户端开发人员，我考虑让 Web API 遵循一个与客户端共享的接口，类似于以下内容。

使用“共享”接口的目的主要是为了使对 Web API 的更改能够在编译时被客户端开发人员检测到。此外，客户端可以利用该接口来创建 HttpClient 实例的包装器，以便用于与 Web API 通信。

客户端开发人员希望在整个实现过程中使用 async 和 await，我又有什么理由说“不”呢？

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

- Sigurd Garshol

---

只要使用异步编程，就没有什么缺点，除非你用错了。 - Jose Francis

用正则表达式解决问题就像是你有了两个问题一样？ - Sigurd Garshol

Answer 1

何时使用Async：

1. 异步API调用。
2. 长时间运行的数据库查询。
3. 需要CPU绑定的任务。
4. 当您需要实现并行性时。

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

注意：请注意死锁问题，因为编译器允许您编写并成功编译异步代码，即使您没有理解其基本概念。

- Jose Francis

Answer 2

使用共享接口的目的主要是为了使客户端开发人员在编译时能够检测到Web API的更改。

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

话虽如此，如果您想将异步方法同步实现，没有任何阻止的因素。我能想到的唯一的问题是，如果您使用的是完整的ASP.NET，则异步操作不能是子操作。在ASP.NET Core上不再存在此限制。

- Stephen Cleary