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