rest - 使用阻塞 REST 请求实现发布/订阅

Question

我最近被要求调查与希望使用 RESTful Web 服务提供电话事件（例如线路振铃、分机应答、呼叫清除）的电话系统供应商集成的可行性。

我指出 REST 是一个请求/响应协议，他们正在做发布/订阅。他们建议的解决方案是发出一个 HTTP REST 请求，该请求将阻塞并最终在事件可用或超时时做出响应。

无论哪种方式，都会发出另一个请求以获取下一个事件，依此类推。

这个想法让我感到畏缩，但我确信 iPhone“推送”电子邮件是这样操作的。

这是对 REST 的合理使用吗？

Answer 1

我会说它不适合 REST 架构风格（主要是因为 REST 将其限制为无状态的客户端服务器交互）。然而，网络有很多可以进行长轮询的解决方案，而且它或多或少是有效的，尽管它不符合网络的精神。

首先，关于架构的说明：在 REST 中实现 pub/sub 仅仅意味着发布者将项目添加到列表中，然后该列表可供订阅者使用。订户轮询该列表。有一些方法可以确保一次且仅一次，同时保持消息顺序和（一种）保证传递，尽管是异步的。它的扩展性非常好，并且非常有弹性。

我的第一条建议是让它成为可选的，这样不能执行长轮询（或不想）的客户可以这样做。我什至会说，如果一个通用客户端（如谷歌）默认不会执行长轮询，并且服务器通过您的客户端和服务器之间的特殊共享理解来启动长轮询. 这种共享的理解可能是自定义媒体类型或自定义链接关系，甚至是通用客户端不知道的自定义 HTTP 标头。支持您的长轮询的客户端将被编码以发现长轮询的功能，并在必要时调用它，如果长轮询失败（例如，中介以某种方式阻止它），则退回到常规轮询。

而不是尝试在 HTTP 之上执行此操作，我建议为此使用非 HTTP 套接字，以免违反 HTTP 的意图并有效地使用 HTTP 作为传输协议。见彗星。

我的另一条建议是问你的客户必须有多“实时”。如果几秒钟的延迟是可以接受的，那么您可以通过定期轮询来做很多事情，即使对于非常大量的客户端，由于使用定期轮询解决此问题的可缓存特性。