我最近被要求调查与希望使用 RESTful Web 服务提供电话事件(例如线路响铃、分机应答、调用清除)的电话系统供应商集成的可行性。
我指出 REST 是一个请求/响应协议(protocol)，他们正在做发布/订阅。他们建议的解决方案是发出一个 HTTP REST 请求，该请求将阻塞并最终在事件可用或超时时做出响应。
无论哪种方式，都会发出另一个请求以获取下一个事件，依此类推。
这个想法让我感到畏缩，但我确信 iPhone“推送”电子邮件是这样操作的。
这是对 REST 的合理使用吗？
最佳答案
我会说它不适合 REST 架构风格(主要是因为 REST 将其限制为无状态的客户端服务器交互)。然而，网络上有大量的长轮询解决方案，而且它或多或少是有效的，尽管它不符合网络的精神。
首先，关于架构的说明:在 REST 中实现 pub/sub 仅仅意味着发布者将项目添加到列表中，然后订阅者可以使用该列表。订户轮询该列表。有一些方法可以确保一次且仅一次，同时保持消息顺序和(一种)有保证的传递，尽管是异步的。它的扩展性非常好，并且非常有弹性。
我的第一条建议是将其设为可选，以便无法执行长轮询(或不想执行)的客户可以这样做。我什至会说，如果一个通用客户端(如谷歌)默认不会执行长轮询，并且服务器通过您的客户端和服务器之间的特殊共享理解来启动长轮询.这种共享的理解可能是自定义媒体类型或自定义链接关系，甚至是通用客户端不知道的自定义 HTTP header 。支持您的长轮询的客户将被编码为 发现长轮询的功能 ，并在必要时调用它，如果长轮询失败(例如，中介以某种方式阻止它)，则退回到常规轮询。
而不是尝试在 HTTP 之上执行此操作，我建议为此使用非 HTTP 套接字，以免违反 HTTP 的意图并有效地使用 HTTP 作为传输协议(protocol)。见 cometd 。
我的另一条建议是问你的客户必须有多“实时”。如果几秒钟的延迟是可以接受的，那么您可以通过定期轮询来做很多事情，即使对于非常大量的客户端，由于使用定期轮询解决此问题的可缓存特性。
关于rest - 使用阻塞 REST 请求实现发布/订阅，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3780086/