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