是否有任何最佳实践规定异步调用与其相应响应之间的最长时间。
基本上我有一个需要很长时间才能运行的过程（例如：5分钟）。 选项1：我可以将进程公开为异步调用。在这种情况下，用户调用我的服务，然后在稍后的某个时间，我回复进程状态。
选项2 我可以实现它的另一种方法是设置系统，使得我的Web服务上有一个单向操作，它开始进程并立即返回进程的id。然后，我可以强制要求消费者提供单向操作，我可以在完成该过程时调用并报告。
第一个选项更容易，因为我不需要从调用者那里强制执行任何操作。第二个似乎更好，因为我可以随时报告（5分钟到几年后）。
由于我可以完全控制来电者及其内部可用服务，因此我倾向于选项2.
所以我想知道是否对异步调用施加了任何时间限制（它们可以跨越几天吗？如果不是最佳做法）。选项2是否采用标准模式？
参考文献非常有用。
答案 0 :(得分：2)
选项＃2更好，因为它更受事件驱动。
但是，存在选项＃3。客户端向服务器发出请求。服务器队列请求并以id响应。客户经常检查，传递请求ID，看看它是否已经完成。
这样，您就不必依赖请求完成时客户端可用。
我可能会混合选项＃2和＃3，让客户选择他们是希望在他们身边发起一个事件，还是只是想稍后再回来查看。
<强>更新
Rajah询问了异步请求和响应之间的最长时间。对于WEB应用程序，通常以秒为单位进行测量。大多数服务器的超时值通常在30秒范围内默认。就个人而言，我认为这太长了。
考虑到异步调用要求客户端和服务器之间的通信通道持续打开。单个服务器可以处理多少个频道？更重要的是，在提出请求时您需要维护多少个频道？即使你控制两端，这也会变得非常无耻。
无论托管您的服务是什么，都将决定保持请求开放的最长时间。同样，我见过的每台服务器都会在几秒钟内完成测量。