对 RESTful API 的异步请求是否应该有单独的 URI？答案

【问题标题】：Should asynchronous requests to a RESTful API have a separate URI?对 RESTful API 的异步请求是否应该有单独的 URI？
【发布时间】：2021-05-02 22:58:27
【问题描述】：

考虑一个带有需要很长时间的方法的 Web API。客户端既可以发出同步请求并等待响应，也可以发出异步请求并接收标准的202 Accepted 响应和状态链接。

在 RESTful 语义下，这两个选项应该作为两个单独的 URI 存在，还是应该是同一个 URI，在标头参数中带有一个异步选项？

【问题讨论】：

我认为这里的实现方法并不重要。您可以这样做，因为从技术上讲 (url + params + headers + payload) 是定义请求的内容。所以我不认为在这件事上移动参数会有所不同。为了清楚起见，我个人会选择两个不同的网址。
@Phil_1984_ 也许你应该把你的评论变成答案？

标签： rest asynchronous asp.net-web-api

【解决方案1】：

它们不一定需要有单独的 URL。 取决于您的 RESTful 服务如何运行和响应。请求由以下内容定义：

请求类型
网址（包括参数）
标题
有效载荷

请求类型（例如 PUT 与 POST）和一些标头（例如缓存）中存在标准。有效负载格式也可以由 Content-Type 标头定义。但是，没有特定的 REST 相关规则规定您必须使用某种 URL 结构。显然，它需要是一个有效的 URL，但它的结构完全取决于您作为服务开发者。

如果您想让调用者选择是同步还是异步处理它，为了清楚起见，我会选择不同的 URL。

例如

/some/dir/service1?process=async
/some/dir/service1?process=sync

注意：为了清楚起见，我在这里使用正斜杠来表示伪目录名称，但即使这在技术上也不是必需的。

您也可以根据需要使用自定义标头，但您需要自己定义 API。

如果您想在服务器端进行异步/同步选择（可能基于当前服务器负载），您可以在单个 url 中实现两者。您应该确保您的 API 有清晰的文档，以便开发人员了解这两种响应格式。

【讨论】：

【解决方案2】：

考虑到这些原因，我会将它分成不同的 URL（我相信其他人会发现更多）：

它将能够将操作分离到不同的方法、类甚至服务。
在需要时取消其中一个会更容易。例如将所有异步处理从 REST 移至消息队列。
代码中的意大利面条更少。

【讨论】：