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