BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

WebSockets与REST之争?

| 作者 Mark Little 关注 14 他的粉丝 ,译者 吴宇 关注 0 他的粉丝 发布于 2012年3月2日. 估计阅读时间: 7 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

纳闷 by wang aj

我觉得,这应该web发展的必然趋势。两者,各有各的应用领域,websocket的诞生是为了解决B/S模式下长连接的问题,而rest更多地是目前大多数web引用搭建的设计风格和理念。
应该说,是相互协作,共同解决日益细化的需求

WebSocket将在中间件领域大有可为 by net chtg

WebSocket将在中间件领域大有可为,只是人们还没有意识到这一点,想象一下Workflow或MOM,利用WebSocket与Web应用融合将是一件非常了不起的事情,现在基本上还是两张皮,为了将不同应用连接起来,只能从更底层做数据交换。利用WebSocket应该可以提供更上层的接口,让中间件更扁平化,如果一个应用的Action能够直接激发另一个应用的Action,会少走很多弯路。一个简单例子:两个应用都有面向客户的相同信息录入界面,比如新闻稿,用户在一个应用中录入的信息出了自己存储之外,还可以通过WebSocket方式的MOM直接激发另一个应用的业务处理逻辑,而不用重新另外编写更底层代码,岂不是更好?

至于WebSocket面向客户方面的应用,感觉应该与REST会共存,长连接和短连接各自有各自的应用环境,不顾服务器压力和连接维护量去片面追捧WebSocket是不可取的,就拿普通网页浏览来说,一个网页往往有很多服务器提供资源,不可能就仅通过建立一个连接来完成,当然,如果针对ajax中经常性数据交换环境,适当搭一下WebSocket可能是可取的

关公大战秦琼 by big king

想表达什么意思呢?
WebSocket会破坏REST?那是一定的。

Re: WebSocket将在中间件领域大有可为 by liao jian

非常同意,WebSocket应该成为所有Data Services的必备功能...

WebSockets和REST比是严重的倒退。 by 典 刘

基于超媒体的资源访问和原始的字节流,实在看不出有什么可争的。个人觉得WebSockets最多也就在集成旧系统上有用。至于Push,Comet 和 自定义的基于TCP的协议效率上没有区别。

寻找各自的位置 by 东喆 王

技术的出现都是为了解决特定问题的,所以他们两个应该不会说竞争关系,应该说根据具体情况,使用的人需要做出正确的选择。即使最后某一方最后消失了,也是因为有新的技术能够代替它的所有功能才会这样的。

WebSocket 不是 Web by L Jakit

这几年,SPA Frontend 的频频出现,其实是 WS 最佳的施展时机。
长链接几乎是客户端的作为,Web 的主体思想是【查询】,查询就是 Request & Response。
WS 根本没那个必要去掩饰自己打算让 WebPage 变成客户端的事实。
吾辈认为,HTTP 2.0 根本也不是 Web,而是面向客户端的协议,我觉得 HTTP 2.0 是很尴尬的存在,不 WS 也不 Web,我觉得为何不干脆 WS 算了,搞得稀奇古怪的。
我不赞成长链接,如果是 SPA 的话,还不如干脆运行客户端算了,限制一大堆,而且 JavaScript 受到叫做【浏览器】这种东西的约束,无论哪一种,网络程序都是不如单机程序靠谱的。
FireFox OS 手机就是个活生生的例子,手机装的都是 SPA,这样的设备适合那种很廉价品充斥的时代,然后一批开发者作为超级廉价的员工,公司不愿出钱的时候,网络程序的引擎(比如浏览器已经能够彻底跟硬件无缝发挥各种特性的时候)。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

7 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT