基于Web的实时通信是否与REST范式不兼容？

Question

在过去的几年中,Web应用程序经历了一次巨大的范式转变.

十年前(不幸的是,甚至现在),Web应用程序只存在于加权服务器中,处理从数据到表示格式的所有内容,并发送到仅呈现服务器(浏览器)输出的哑客户端.

然后AJAX加入了游戏,Web应用程序开始变成服务器和浏览器之间的东西.

在AJAX的高潮期间,Web应用程序逻辑开始完全在浏览器上运行.我认为这是在HTTP RESTful API开始出现的时候.突然间,每个新服务都有它的 RESTful API,突然间,JavaScript MV*框架开始像popcorns一样弹出.移动设备的使用也大大增加,REST非常适合这种情况.我在这里说"有点RESTful",因为几乎所有声称都是REST的API都不是.但那是一个完全不同的故事.

事实上,我成了一名" REST传播者 ".

当我认为Web应用程序无法发展得更多时,一个新的时代似乎正在曙光:有状态的持久连接Web应用程序. Meteor是这种应用程序的杰出框架的一个例子.然后我看了这个视频.在这个视频中,Matt Debergalis谈到Meteor,两人都做得非常出色!然而,他有点为了这种目的而放弃REST API,以支持持久的实时连接.

例如,我非常希望能够进行实时模型更新,但仍然拥有所有REST非常棒的功能. 流式REST API看起来就像我需要的那样(例如,firehose.io和Twitter的API),但这种新型API的信息非常少.

所以我的问题是:

基于Web的实时通信是否与REST范式不兼容？

(很抱歉很长的介绍性文字,但我认为这个问题只适用于某些背景)

Answer 1

只要您不四处走动，Web 应用程序的有状态持久 tcp/ip 连接就很棒。

我开发了一个基于实时 Web 的框架，根据我的经验，我发现当使用基于移动设备的 Web 浏览器时，IP 地址会随着我从一个塔移动到另一个塔，或者从一个 Wi-Fi 移动到另一个 Wi-Fi，而不断变化。

当 IP 地址不断变化时，持久连接的概念很快就会消失。

实时 Web 应用程序的框架必须假设连接是暂时的，并且框架必须实现自己的会话概念，同时到后端的底层 IP 连接不断变化。

一旦会话被定义并在客户端和服务器之间的所有请求和响应中使用，基本上就拥有了“Web 连接”。现在，人们可以使用 REST 范例开发基于实时 Web 的应用程序。

框架的后端服务器必须智能地在 IP 地址发生转换时对更新进行排队，然后在重新建立 tcp/ip 连接时进行同步。

简短的回答是，“是的，您可以使用 REST 范例来开发基于 Web 的实时应用程序”。

如果你想和我一起玩，请告诉我。