十年前(不幸的是甚至现在),网络应用程序只能在重量级的服务器上生活,处理从数据到表示格式的所有内容,并发送给只提供服务器(浏览器)输出的哑客户端.
然后,AJAX加入了游戏,Web应用程序开始变成在服务器和浏览器之间生活的东西.
在AJAX的高潮期间,Web应用程序逻辑开始完全在浏览器上运行.我认为这是HTTP RESTful API开始出现的时候.突然间,每一个新服务都有其RESTful API,并且突然之间,JavaScript MV *框架开始像爆米花一样弹出.移动设备的使用也大大增加,REST适合这些场景.我在这里说“亲切的RESTful”,因为几乎所有声称是REST的API都不是.但这是一个完全不同的故事.
其实我成了一种“REST传福音”.
当我认为网络应用程序不能演变得更多时,一个新的时代似乎是曙光：状态持久连接的网络应用程序.
Meteor是这种应用的辉煌框架的例子.然后我看到了这个video.在这个视频中,Matt Debergalis谈到了流星,都做了一个奇妙的工作！
然而,他为了这种目的而减少了REST API,有利于持续的实时连接.
我非常希望有实时模型更新,例如,但仍然具有所有的REST awesomeness.
流式REST API似乎像我需要的(例如firehose.io和Twitter的API),但是这种新型API的信息很少.
所以我的问题是：
基于Web的实时通信与REST模式不兼容吗？
(对于很长的介绍性文本,但是我认为这个问题在某些情况下才会有意义)
解决方法
我已经开发了一个基于Web的实时框架,根据我的经验,我发现使用基于移动设备的网络浏览器时,我从塔到塔,Wi-Fi到Wi-Fi都不断变化.
当IP地址不断变化时,持久连接的概念会很快地消失.
实时Web应用程序的框架必须被设计为假设连接将是暂时的,并且框架必须实现自己的会话概念,而到后端的底层IP连接不断变化.
一旦会话被定义并在客户机和服务器之间的所有请求和响应中使用,一个实质上具有“web连接”.现在,可以使用REST模式开发实时的基于Web的应用程序.
框架的后端服务器必须智能地排队更新,而IP地址正在进行转换,然后在重新建立tcp / ip连接时同步.
简短的答案是,“是的,您可以使用REST范例实现基于Web的实时应用”.
如果你想玩一个,让我知道.
