9

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

十年前（不幸的是，即使是现在），Web 应用程序只存在于重量级的服务器中，处理从数据到表示格式的所有内容，并发送到只呈现服务器（浏览器）输出的愚蠢客户端。

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

在 AJAX 的高潮期间，Web 应用程序逻辑开始完全依赖于浏览器。我认为这是 HTTP RESTful API 开始出现的时候。突然之间，每一项新服务都有其类型的RESTful API，突然之间，JavaScript MV* 框架开始像爆米花一样突然出现。移动设备的使用也大大增加，REST 非常适合这类场景。我在这里说“一种 RESTful”，因为几乎所有声称是 REST 的 API 都不是。但这是一个完全不同的故事。

事实上，我成了某种“ REST 布道者”。

当我认为 Web 应用程序无法进一步发展时，一个新时代似乎正在来临：有状态的持久连接 Web 应用程序。 Meteor是此类应用程序的出色框架的一个示例。然后我看到了这个视频。在这段视频中，Matt Debergalis 谈到了 Meteor，两者都做得非常出色！然而，他出于这种目的而降低了 REST API，以支持持久的实时连接。

例如，我非常希望有实时模型更新，但仍然拥有所有 REST 的魅力。 流式 REST API似乎是我所需要的（例如 firehose.io 和 Twitter 的 API），但是关于这种新型 API 的信息很少。

所以我的问题是：

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

（很抱歉介绍性文字很长，但我认为这个问题只有在某些情况下才有意义）

4

3 回答 3

3

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

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

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

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

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

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

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

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

于 2012-12-17T19:57:10.603 回答
2

我对这个话题也很感兴趣。这篇文章有一些论文链接，这些论文讨论了设计不佳的 RPC 的一些问题：

http://thomasdavis.github.com/2012/04/11/the-obligatory-refutation-of-rpc.html

我并不是说 Meteor 设计不佳，因为我对 Meteor 了解不多。

无论如何，我想我想要两个“世界”中最好的。我想从 REST 以及它提供的所有受约束的通用接口、可寻址性、无状态等中受益。

而且，我也不想在这场“实时”网络革命中落后！这绝对是非常棒的。

我想知道是否没有可以工作的混合方法：

RESTful 端点可以允许客户端进入空间，并按照 HATEOAS 的要求跟踪相关文档的链接。但是，对于资源的“更新流”，也许“订阅名称”本身可能是一个 URI，当在一个时间点单个请求中浏览到它时，例如通过 Web 浏览器的地址栏或 curl，会返回“当前状态”的表示，或带有 href 的链接列表以获取资源的先前状态和/或查询针对对象发生的离散“事件”的方法。

这样，如果您使用实体的“版本 1”声明，然后针对它重播每个事件，您可以将其更改为“当前状态”，并且这些事件可以流式传输到执行该操作的客户端不想仅仅因为实体的一小部分发生了变化就得到完整的表示。这基本上是“事件存储”的概念，其中包含许多 CQRS 信息。

就 REST 兼容而言，我相信这种方法已经完成（虽然我不确定这方面的流媒体），我不记得它是否在这本书中http://shop.oreilly.com/product /9780596805838.do（实践中的 REST），或者在我听到的 Vaughn Vernon 在 QCon 2010 录制的演讲中的演讲中：http: //www.infoq.com/presentations/RESTful-SOA-DDD。

他谈到了类似这样的 URI 设计（我记不太清了）

host/entity <-- 资源的当前版本 host/entity/events <-- 将对象改变为当前状态的事件列表

例子：

host/entity/events/1 <--这将对应于实体的创建 host/entity/events/2 <--这将对应于针对实体的第二个事件

他可能也有一些关于历史的东西，完整的时间状态，比如：

host/entity/version/2 <-- 这将是上述事件 2 之后实体的整个状态。

Vaughn 最近出版了一本书，《实现领域驱动设计》，从目录来看，它涵盖了 REST 和事件驱动架构：http ://www.amazon.com/gp/product/0321834577

于 2013-02-02T04:46:19.280 回答
0

我是http://firehose.io/的作者，这是一个基于 Streaming RESTful API 可以并且应该存在的前提的实时框架。来自项目网站：

Firehose 是一种构建实时 Web 应用程序的微创方式，无需复杂的协议或从头开始重写您的应用程序。它是一个简单的发布/订阅服务器，通过 WebSockets 或 HTTP 长轮询使客户端 Javascript 模型与服务器代码保持同步。它完全包含 RESTful 设计模式，这意味着您在构建应用程序后将获得一个不错的 API。

我希望这个框架可以防止 Internet 回到 RPC 黑暗时代，但我们会看看会发生什么。我们确实在Poll Everywhere的生产环境中使用 Firehose.io，每天向各种不同设备上的人们推送数百万条消息。有用。

于 2013-09-11T04:46:02.707 回答