WebSockets 与 REST 之争?

  • Mark Little
  • 吴宇

2012 年 3 月 1 日

话题:REST语言 & 开发架构

在过去的几年中,WebSockets变得越来越流行并积累了不少用户。去年年底,WebSockets 成为了W3C 的推荐候选,这使得其向标准更迈进了一步。Oracle 等其他厂商最近也提交了申请,来启动在 Java 企业版的下一个版本中引入 WebSockets(JSR 356)的标准流程工作。绝大部分的主流浏览器,如 Chrome、Firefox、Safari 和 IE,都支持某个 WebSockets 修正本,并最终会采用最后成形的标准。在较短时间内WebSockets 几乎已经成为了Web 不可分割的一部分。尽管如此,仍有一些开发者对 WebSockets 将会如何或者是否能够融入到 Web 架构风格:REST 持保留意见。有一些人,如 Nathan Evans,针对这一问题则表示WebSockets 会使得 REST 相形见绌:

在仔细研读了 WebSockets 标准并吸收了各种相关的在线讨论后,我越来越清楚地了解到该标准打算窃取 RESTful web 服务所分享的绝大部分想法。我想说的是,将来在产品开发的某个阶段,一定会有人提出这么一个问题:

"好吧伙计们,在这个项目中我们是应该使用 WebSockets 还是 REST?"

我预计 WebSocketes 将在一到两年内,开始阻碍 RESTful web 服务的发展——至少依目前的形势来看是这样的。

Nathan 在其文章中认为就他使用 REST 的经验来看,其实 REST 并不像有些人描绘的那样是所谓的“杀手锏”,当然了在他看来 WebSockets 也不尽完美。他随后罗列了几个为何 WebSockets 会成为 REST 威胁的原因,如 REST 框架依赖于标准较低的基于文本的协议。相对于 REST,WebSockets 提供了包括双向交互在内的一些较为重要的利好:

WebSockets 所提供的真正的双向交互能力对任何衍生于 HTTP 的协议来说,都是前所未有的。这种能力既不被 SOAP 也不被 REST 所拥有。而 Comet/ 推(push)/ 长轮询(long-polling)也只能模拟,而且效率并不高。双向交互能力从根本上说是相当好的,只要你愿意,你可以在 WebSocket 之上的远程桌面或 VNC 开通一个实时 TCP 协议通道。

Nathan 坚信 WebSockets 带来的诸多好处远超 REST(HTTP)所能提供的,开发人员终将会选择转移到 WebSockets 上来。

对那些需要较高可视性且跨平台的可交互 web 服务的项目来说,REST 可能还将是其默认选项。而对于没有上述要求的项目而言,WebSockets 将有机会取而代之,运行在其之上的要么是 JSON,要么使用自定义的端协议。[……] 尽管两者是竞争关系,但好在 REST 和 WebSockets 其实可以相互共存。事实上,由于它们都是在 HTTP 基础之上衍生的,所以两者是可以兼容的。

然而,Nathan 不是唯一一个抛出“使用 WebSockets 还是 REST”这类问题的人。比如,Shay Bannon早在 2010 年就提出是否有可能在使用 WebSockets 时利用 REST 的一些原则:

首先要搞清楚的是,你如何来描述一个 URI?其次,如何描述 HTTP 方法(GET、PUT、POST 等)?最后,如何描述 HTTP URI 参数和消息头?似乎可以通过往消息内容(文本字符串)中构建某些模式(schema)的方法来解决。就像一个包含“uri”、“params”等域的 JSON 字符串那样。这样想就太复杂了,因为使用 HTTP,你可以创建一个非常简单的防火墙,只简单利用消息头或参数,而无需解析消息体……

他想知道为何 WebSockets 没有 URI 或消息头的概念,这样看来,在大家重新改造 REST 并导致所谓的“非统一风格”之前,是否需要一个在 WebSockets 之上的 REST 规范?那个时候他收到了很多人对此文章的回应。比如,其中一个声称自己之前在一家 WebSockets 公司工作的人(所以其观点可能不太客观)回复道:

REST 和 WebSocket 通信看起来是两种不同的分布式计算风格。REST 就像传统派,在 HTTP 之上,同步的 web rpc 风格。WebSockets 则像新兴派,是 HTTP 的延伸,通常是异步的 web 通信风格。恕我直言,长远来看,WebSocket 将会极大的减少对 WAN 计算的 REST 需求。使用 WebSocket,那些在过去几十年中我们所熟知和喜爱的协议都可以在 web 上得以扩展,而无需担心映射到 HTTP 上的笨拙和性能短板。

另外也有人回复道:

我的想法是 REST 引入了传统的请求 / 应答范例。相反,WebSockets 迎合了 comet/ 长轮询的场景,其通信范围可以在几个通信周期中保持开放。并且,WS 最初的握手仍然发生于 HTTP,所以实际上,它们并不相互排斥。我也认为 WS 协议的要点在于摆脱 HTTP 消息头的鬼把戏,因为它已经变得冗余,只会凭添消息负载。

然而,虽然基本达成 REST 和 WebSockets 能够也应该共存的共识,但一些留言者完全不认同关于在 WebSockets 之上的 REST 的概念,其中有人谈到:

如果你以 Fielding 的观点来考虑 REST,将其作为一种可定位对象(或资源)的 web,那么这在双重通信格式上是行不通的。你不能指望资源能自己发起会话。WebSockets 将会转换 web(如果它们发起的话),但不是作为针对 REST 风格通信的一种协议。

还有人给出了该观点的更深细节分析:

WebSockets 就像用 ADD 通话的两个人。完全是双向的,两边都可以同时说话,在对方讲话时,两边也都要拿起自己的听筒。REST 是无状态以及同步的,只处理请求 -> 回应。你只能自己扩展 REST 的概念以期得到服务器(主动发起)-> 客户端通信的利好。我可以看到 WebSockets 中存在一个实现 REST 的库,但这只对已经拥有 RESTful API,并想得到削减开销的利好(一个连接即可,无需重构其代码)的应用有用。

当然了,在 REST 社区也存在一些人,比如 Jim Webber,他们坚信 WebSockets不会给 web 带来好处

Jim Webber tweet

随着 WebSockets 几乎已经成为了一种标准,而且被浏览器、移动设备以及所支持和使用,我们倒很有兴趣来了解一下这会对那些当前使用 REST 和 HTTP 的开发者带来多大影响,或者会被一个不同的开发者团体所接受?更糟的是,是否像某些人所坚信的那样,我们已经处在“Web 正在被破坏”的危险之中?

查看英文原文:WebSockets versus REST?

REST语言 & 开发架构