过去几年，网络应用程序经历了一次巨大的范式转变。
十年前（不幸的是，即使是现在），网络应用程序只存在于重型服务器中，处理从数据到表示格式的所有内容，并发送到仅呈现服务器输出的哑客户端（浏览器）。
然后AJAX加入了游戏，网络应用程序开始变成服务器和浏览器之间的东西。
在AJAX的高潮期间，Web应用程序逻辑开始完全在浏览器上运行。我认为这是在HTTP RESTful API开始出现的时候。突然间，每个新服务都有 种 RESTful API，突然间，JavaScript MV *框架开始像popcorns一样弹出。移动设备的使用也大大增加，REST非常适合这种情况。我在这里说“有点RESTful”，因为几乎所有声称都是REST的API都不是。但那是一个完全不同的故事。
事实上，我成了一名“ REST传播者”。
当我认为Web应用程序无法发展得更多时，一个新时代似乎已经开始：有状态的持久连接Web应用程序。 Meteor是这种应用程序的精彩框架的一个例子。然后我看到了video。在这个视频中，Matt Debergalis谈到Meteor，两人都做得非常出色！ 然而，他有点为了这种目的而放弃REST API，而不是持久的实时连接。
我非常希望能够进行实时模型更新，例如，但仍然拥有所有REST非常棒的功能。 流式REST API 看起来就像我需要的那样（例如，firehose.io和Twitter的API），但这种新型API的信息非常少。
所以我的问题是：
基于网络的实时通信是否与REST范式不兼容？
（很抱歉这篇长篇介绍性文字，但我认为这个问题只适用于某些背景）
答案 0 :(得分：3)
只要您没有四处移动，Web应用程序的有状态持久性tcp / ip连接就很棒。
我已经开发了一个基于Web的实时框架，根据我的经验，我发现当使用基于移动设备的Web浏览器时，随着我从一个塔移动到另一个塔，或者wi-fi到wi，IP地址不断变化网络连接。
当IP地址不断变化时，它是一个持久连接的概念会很快消失。
实时网络应用程序的框架必须构建，假设连接是暂时的，框架必须实现自己的会话概念，而后端的底层IP连接不断变化。
在客户端和服务器之间的所有请求和响应中定义并使用会话后，一个会话基本上具有“Web连接”。现在，人们可以使用REST范例开发基于Web的实时应用程序。
框架的后端服务器必须是智能的，以便在IP地址正在进行转换时排队更新，然后在重新建立tcp / ip连接时进行同步。
简短的回答是，“是的，您可以使用REST范例进行基于Web的实时应用程序”。
如果你想玩一个，请告诉我。
答案 1 :(得分：2)
我对这个话题也非常感兴趣。这篇文章有一些链接到论文，讨论设计不良的RPC的一些麻烦：
http://thomasdavis.github.com/2012/04/11/the-obligatory-refutation-of-rpc.html
我不是说Meteor的设计很差，因为我对Meteor不太了解。
无论如何，我想我想要两者兼顾“世界”。我希望受益于REST以及它所提供的受限通用接口，可寻址性，无状态等等。
而且，我也不想在这场“实时”网络革命中落后！这绝对是非常棒的。
我想知道是否有可行的混合方法：
RESTful端点可以允许客户端输入空间，并按照HATEOAS调用的方式跟踪指向相关文档的链接。但是，对于资源的“更新流”，也许“订阅名称”本身可能是一个URI，当在一个时间点单个请求中浏览时，就像通过Web浏览器的地址栏或卷曲一样，返回“当前状态”的表示，或者具有用于资源的先前状态的href的链接列表和/或查询已经针对该对象发生的离散“事件”的方式。
通过这种方式，如果您使用实体的“版本1”进行声明，然后针对它重放每个事件，您可以将其变为“当前状态”，并且此事件可以流式传输到不希望仅仅因为实体的一小部分已经改变而得到完整表示的客户端。这基本上是“事件存储”的概念，其中包含许多CQRS信息。
就REST兼容而言，我相信这种方法已经完成（虽然我不确定这方面的流媒体方面），我不记得是否在本书中http://shop.oreilly.com/product/9780596805838.do（REST in练习），或者在Vaughn Vernon在2010年QCon上的录音演讲中听到的演讲：http://www.infoq.com/presentations/RESTful-SOA-DDD。
他谈到了类似这样的URI设计（我不记得确切）
host / entity＆lt; - 资源的当前版本 host / entity / events＆lt; - 将对象变为当前状态的事件列表
示例：
host / entity / events / 1＆lt; - 这将对应于实体的创建 host / entity / events / 2＆lt; - 这将对应于有关实体的第二个事件
他可能也有历史的东西，完整的时间状态，如：
host / entity / version / 2＆lt; - 这将是上述事件2之后的实体的整个状态。
Vaughn最近出版了一本书“实现领域驱动设计”，该书从内容列表看起来涵盖了REST和事件驱动架构：http://www.amazon.com/gp/product/0321834577
答案 2 :(得分：0)
我是http://firehose.io/的作者，这是一个基于Streaming RESTful API可以而且应该存在的前提的实时框架。来自项目网站：
Firehose是一种构建实时网络应用程序的微创方式 没有复杂的协议或从头开始重写您的应用程序。它是 简单的pub / sub服务器，用于保存客户端Javascript模型 通过WebSockets或HTTP长轮询与服务器代码同步。的它 完全接受RESTful设计模式，这意味着你最终会得到 构建应用程序后的一个很好的API。
我希望这个框架能够阻止互联网回到RPC黑暗时代，但我们会看到会发生什么。我们确实在Poll Everywhere的生产中使用Firehose.io，每天将数百万封邮件发送给各种不同设备上的用户。它有效。