2

我正在尝试扩展 WebAPI 以支持通过 HTTP 回调返回响应。

工作流程:

  1. WebAPI 接收带有回调 URL 的 HTTP 请求。
  2. WebAPI 正常处理 URL,如果操作完成的时间少于配置的超时时间,则同步发送结果。
  3. 如果超过了超时,服务器需要发送一个 HTTP 响应,表明它已经异步,处理继续。
  4. 当处理(最终)完成时,控制器的响应将发布到预先协商的回调 url。

控制器需要保持同步并且不知道异步/回调功能。

似乎 MessageHandlers 是一个可能的候选者,但似乎不支持返回多个 HTTP 响应(一个用于早期的“长任务”响应,一个用于回调)。

有人可以就 WebAPI 的哪些领域可扩展并与此方案相关提供指导吗?

4

1 回答 1

0

我认为 HttpMessageHandler 可以解决问题,但不是我认为您要求的方式。

一个 URL 将是主要 URL,将返回结果或重定向,另一个将处理重定向。

这是一个非常常见的场景。在某些情况下,您会要求提供一些内容的列表并接收管理数量的结果和一个延续 URL(如果有更多)。您的需求可能会被视为您只有一个延续或整个结果的地方。

另一种将其视为 CQRS(命令查询责任分离)的方式。您在 URL 上发出命令并从另一个检索响应。作为优化,调用命令的结果可能是响应而不是查询 URL。

这对你有帮助吗?

于 2013-05-02T21:09:19.353 回答