在 api 中提供可选同步方法的优雅方式？答案

【问题标题】：Elegant way to provide optional synchronous methods in an api?在 api 中提供可选同步方法的优雅方式？
【发布时间】：2018-06-01 12:53:14
【问题描述】：

我编写了一个安全 Web API，所有控制器级别的方法都是异步的。我的想法是下游客户可以根据需要简单地“等待”同步处理的方法。

但是，我遇到了一种情况，即 ASP.NET MVC（预核心）中的 AuthorizationAttribute 不支持异步方法挂钩。所以我需要能够提供其中一些方法的可选同步版本。

有什么优雅的方法可以做到这一点？例如，假设我目前定义了以下路由来获取用户：

api/v1/users/{userGuid}

这是方法签名：

public async Task<IHttpActionResult> GetUserAsync(Guid id, [FromUri] string expand=null)

如何更新我的 API 以提供此方法的同步版本？看来我需要更新 uri 以适应这种情况：

api/v1/users/{userGuid}/synchronous

否则，我还能如何识别和处理对特定 API 方法的同步版本的请求？

【问题讨论】：

【解决方案1】：

我认为您对 async 控制器方法的真正含义感到困惑。 async 和 await 不会影响 API 本身，只会影响实现。

public async Task<IHttpActionResult> GetUserAsync(Guid id, [FromUri] string expand=null)

当您异步实现一个动作处理程序时，这意味着 Web API 框架可以使用线程来处理其他工作的请求，而它是 awaiting 异步操作的结果（例如查询您的数据库）。这有助于通过增加在相同硬件上可以处理的请求负载来扩展您的服务。

对调用者没有任何影响。对于您的 HTTP 客户端，无论是否同步处理，请求看起来都是一样的。仍然有一个 HTTP 请求进入，一个 HTTP 响应通过同一个套接字连接返回。

现在，如果您的客户端对您的 API 使用异步调用，它可能会在您的服务处理请求并产生响应时放弃它正在调用的线程。如果客户端是一个 HTTP 服务本身，或者一个带有消息泵的应用程序，这可能很有用。

但无论哪种情况，无论 API 是否使用 async 方法实现，它都会在同一端点上调用 API。

【讨论】：