Web应用程序在过去几年中经历了一次巨大的范式转变。
十年前(不幸的是，即使是现在)，web应用程序只存在于重量级的服务器中，处理从数据到演示格式的所有内容，并发送到只提供服务器(浏览器)输出的愚蠢客户端。
然后AJAX加入了游戏，网络应用程序开始变成介于服务器和浏览器之间的东西。
在AJAX的高潮时期，web应用程序逻辑开始完全依赖于浏览器。我认为这是HTTP RESTful API开始出现的时候。突然间，每一个新服务都有了种类的RESTful API，JavaScript MV*框架开始像爆米花一样弹出。移动设备的使用也大大增加，REST非常适合这类场景。我在这里说"kind-ofRESTful"是因为几乎所有声称是REST的API都不是。但情况完全不同。
事实上，我成了一个">REST传播者"。
当我认为web应用程序无法再进化时，一个新的时代似乎正在到来：有状态的持久连接web应用程序。Meteor就是这类应用程序出色框架的一个例子。然后我看到了这个视频。在这段视频中，Matt Debergalis谈到了Meteor，两人都做得很棒！然而，出于这种目的，他在某种程度上降低了REST API，以支持持久的实时连接。
例如，我非常希望有实时的模型更新，但仍然具有REST的所有优点。流式REST API的似乎是我所需要的(例如firehose.io和Twitter的API)，但关于这种新型API的信息很少。
所以我的问题是：
基于web的实时通信是否与REST范式不兼容
(很抱歉有太长的介绍性文字，但我认为这个问题只有在某些上下文中才有意义)
只要您不移动，用于web应用程序的有状态持久性tcp/ip连接就非常好。
我开发了一个基于网络的实时框架，根据我的经验，我发现在使用基于移动设备的网络浏览器时，当我从一个塔移动到另一个塔，或者从wi-fi移动到wi-fi时，IP地址不断变化。
当IP地址不断变化时，它是一个持久连接的概念很快就会消失。
实时web应用程序的框架必须在构建时假设连接将是瞬态的，并且框架必须实现自己的会话概念，同时与后端的底层IP连接不断变化。
一旦在客户端和服务器之间的所有请求和响应中定义并使用了会话，就基本上拥有了"web连接"。现在，可以使用REST范式开发实时的基于web的应用程序。
框架的后端服务器必须是智能的，以便在IP地址进行转换时排队更新，然后在重新建立tcp/IP连接时同步。
简短的回答是，"是的，你可以使用REST范式做实时的基于web的应用程序"。
如果你想玩一个，请告诉我。
我对这个主题也很感兴趣。这篇文章有一些论文的链接，这些论文讨论了设计糟糕的RPC的一些问题：
http://thomasdavis.github.com/2012/04/11/the-obligatory-refutation-of-rpc.html
我并不是说流星的设计很糟糕，因为我对流星了解不多。
无论如何，我想我想要两全其美的"世界"。我想从REST以及它所提供的受限通用接口、可寻址性、无状态性等方面获益。
而且，我也不想在这场"实时"网络革命中被落在后面！这真是太棒了。
我想知道是否有一种混合方法可以奏效：
RESTful端点可以允许客户端进入一个空间，并按照HAEOAS的要求遵循到相关文档的链接。但是，对于资源的"更新流"，也许"订阅名称"本身可以是一个URI，当在某个时间点浏览到单个请求时，比如通过web浏览器的地址栏或curl，它将返回"当前状态"的表示，或资源先前状态的href链接列表和/或查询对象上发生的离散"事件"的方法。
通过这种方式，如果您使用实体的"版本1"进行状态，然后针对它重播每个事件，您可以将其更改为"当前状态"，并且这些事件可以流式传输到客户端，该客户端不希望仅仅因为实体的一小部分发生了更改就获得完整的表示。这基本上就是"事件存储"的概念，它包含在很多CQRS信息中。
就REST兼容而言，我相信这种方法已经完成了(尽管我不确定它的流媒体方面)，我不记得它是否在这本书中http://shop.oreilly.com/product/9780596805838.do(REST在实践中)，或者我在2010年QCon的一次录音演讲中听到的Vaughn Vernon的演讲：http://www.infoq.com/presentations/RESTful-SOA-DDD.
他谈到了类似这样的URI设计(我记不清了)
主机/实体<--资源的当前版本主机/实体/事件<--将对象突变为其当前状态的事件列表
示例：
主机/实体/事件/1<--这将对应于实体的创建主机/实体/事件/2<--这将对应于有史以来针对实体的第二个事件
他可能也有一些历史性的东西，完全货币化的时间状态，比如：
主机/实体/版本/2<--这将是在上述事件2之后实体的整个状态。
Vaughn最近出版了一本书《实现域驱动设计》，从目录来看，它涵盖了REST和事件驱动架构：http://www.amazon.com/gp/product/0321834577
我是http://firehose.io/，一个基于流式RESTful API可以并且应该存在的前提的实时框架。来自项目网站：
Firehose是一种构建实时web应用程序的微创方式无需复杂的协议或从头开始重写应用程序。这是一个肮脏的简单pub/sub服务器，将客户端Javascript模型保存在通过WebSockets或HTTP长轮询与服务器代码同步它完全包含RESTful设计模式，这意味着您最终会一个很好的API在你建立你的应用程序。
我希望这个框架能防止互联网回到RPC黑暗时代，但我们拭目以待。我们确实在Poll Everywhere的生产中使用Firehose.io，每天在各种不同的设备上向人们推送数百万条消息。它有效。