WebSockets与REST之争?

标签: websockets rest | 发表时间:2012-03-01 21:33 | 作者:
出处:http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

在过去的几年中, 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?

译者 吴宇 关注Java EE,感兴趣的技术领域包括软件架构、SOA、ESB和开源项目等。

相关 [websockets rest] 推荐:

WebSockets与REST之争?

- - 酷勤网-挖经验 [expanded by feedex.net]
WebSockets变得越来越流行并积累了不少用户. 去年年底,WebSockets成为了. W3C的推荐候选,这使得其向标准更迈进了一步. Oracle等其他厂商最近也提交了申请,来启动在Java企业版的下一个版本中引入WebSockets(. JSR 356)的标准流程工作. 绝大部分的主流浏览器,如Chrome、Firefox、Safari和IE,都支持某个WebSockets修正本,并最终会采用最后成形的标准.

HTML5 WebSockets 基础使用教程

- jk - 彬Go
  HTML5之中一个很酷的新特性就是WebSockets,它可以让我们无需AJAX请求即可与服务器端对话. 今天彬Go将让大家通过Php环境的服务器端运行WebSocket,创建客户端并通过WebSockets协议发送和接收服务器端信息. 您还可以参考以下HTML5相关文章:. 《关于HTML 5 canvas 的基础教程》.

经典论文 — REST

- ripwu - kernelchina
牛人Roy Thomas Fielding的博士论文,此处可以访问到英文版,中文版可以google一下. HTTP1.0,1.1版本以及URI规范的主要作者,Apache的co-founder. 在写这篇论文之前已经很牛了,笔者不明白的是这种档次牛人还要读博士,文凭有这么重要吗. 文中没有任何令人眼花的数学公式和统计图表,实际上是一篇描述URI,HTTP设计经验教训总结的文章.

MongoDB REST Api介绍

- peigen - NoSQLFan
MongoDB默认会开启一个HTTP协议的端口提供REST的服务,这个端口是你Server端口加上1000,比如你的Server端口为27017,那么这个HTTP端口就是28017,默认的HTTP端口功能是有限的,你可以通过添加–rest参数启动更多功能. 下面是在这个端口通过其RESTFul 的API操作MongoDB数据的几个例子,来源是MongoDB官方文档.

REST 与 SOAP巅峰对话

- - CSDN博客互联网推荐文章
随着Restful的流行,soap似乎有点贵族落寞了. 下面我们先详细分析一下他们的各自的特点. REST(Representational State Transfer)是 Roy Fielding 提出的一个描述互联系统架构风格的名词. Web 本质上由各种各样的资源组成,资源由 URI 唯一标识.

为啥REST如此重要?

- - 博客园_知识库
  英文原文: Why REST is so important.   本文我们将讨论 REST,它定义了一组体系架构原则,您可以根据这些原则设计以系统资源为中心的 Web 服务,这是一个非常容易让人误解的概念. 本文主要是写给那些想设计 WebService API 但却对 REST 没有十分清晰认识的开发者们.

REST服务开发实战

- - 互联网 - ITeye博客
本文转自http://kb.cnblogs.com/page/91827/.   如果要说什么是REST的话,那最好先从Web(万维网)说起. 读者可以查看维基百科的词条( http://zh.wikipedia.org/zh-cn/Web),具体的我就不多说了. 总之,Web是我们在互联网上最常用的服务,甚至在某些人的心中,互联网就是Web.

REST API性能比较

- - Java - 编程语言 - ITeye博客
REST已然成为最流行的提供外界服务API的方式. 同时,随着互联网和物联网的普及,如今的应用需要处理大量并发的请求. 因此,开发高性能REST服务已经成为一个成功应用的必备条件. 我这里集中讨论Java和JVM相关技术. 基于Java的REST应用比基于python和ruby的应用往往具备更好的性能.

撰写合格的REST API

- - 博客园_知识库
  两周前因为公司一次裁人,好几个人的活都被按在了我头上,这其中的一大部分是一系列REST API,撰写者号称基本完成,我测试了一下,发现尽管从功能的角度来说,这些API实现了spec的显式要求,但是从实际使用的角度,欠缺的东西太多(各种各样的隐式需求). REST API是一个系统的backend和frontend(或者3rd party)打交道的通道,承前启后,有很多很多隐式需求,比如调用接口与RFC保持一致,API的内在和外在的安全性等等,并非提供几个endpoint,返回相应的json数据那么简单.