❏ 站外平台:

选择WebSockets还是REST?

| 2013-06-03 10:45   收藏: 1    

过去的几年,WebSockets逐渐成熟并变得可用。去年年底,WebSockets距离成为标准更近了一步:成为了W3C CR。Oracle和其他一些组织最近也提交了关于在下个版本的Java EE中启动WebSockets标准化的请求。所有的主流浏览器如Chrome,FireFox,Safari和IE都支持众多WebSockets版本中的一种,但如果标准一旦制定,无论如何他们也将最终遵循制定的标准。在一个相对较短的时间里,WebSockets几乎已经成了Web不可分割的一部分。然而,仍然有部分开发者不确定WebSockes是否或者适应Web的架构风格:REST。他们中的一些,例如Nathan Evans就比较激进,他认为WebSockets可能给REST蒙上阴影。

在详细阅读了标准以及吸收了一些网上围绕此话题展开的讨论之后,我日益认为这份标准将占有RESTful服务的大量思想。我的意思是说,未来某个时间在产品开发时将会有人问到: 

"好吧兄弟们,这个产品中我们到底是用WebSockets呢还是REST?" 

我期望在一两年内 WebSockets将开始阻止RESTful Web服务的发展,至少如我们现在所知的那样。

在他的文章中,Nathan认为尽管他承认WebSockets并非完美,但基于他使用REST的经验,REST也不是他人所描述的银弹。然后他列出了WebSockets为何会成为REST的威胁的几条理由,包括“不够格”的REST框架依赖基于文本协议的情况。还有一些相比REST,WebSockets提供的重要好处,比如双向交互的能力。

WebSockets提供的真正的双工通信是任何其他HTTP传输的协议所不具备的,无论它是SOAP还是REST。而Comet,Push和长轮询也只能模拟,还非常低效。双工通信天性就足够好滴允许你建立实时TCP通讯协议,比如RDP或VNC。

Nathan相信WebSockets提供的好处比REST(HTTP)更有用,所以开发者们将会喜欢WebSockets而转向使用它。

REST可能仍将是需要可视性和跨平台互操作性的项目的首选。然而不需要这些特性的项目将很可能选取WebSockets,在其上仍可使用JSON,或 一种预定的通讯协议。尽管他们是竞争者的关系,他们仍可共存.事实上,他们其实是相辅相成的,因为他们都是建立在HTTP基础之上。  

然而,Nathan并非提出"WebSockets or/versus REST"这一问题的唯一一人。例如Shay Bannon在2010年曾提出是否可以在WebSockets中使用REST的原则的一些问题。

首要的是,如何表示一个URL?其次,你如何表示一个HTTP方法?最后,你如何表示HTTP URL参数和HTTP头?看起来一种解决办法是在让内容文本遵循一种规则,就像JSON字符串那样,具有一个URL字段和参数字段等等。但这也是很恼人的,因为在HTTP中,你可以直接使用HTTP头或者参数来很简单地创建连接,而不需要解析内容。

他觉得为何WebSockets就没有“URI”或“头”的概念,因此是否需要一种REST-over-WebSockets的规范,以防止人们重新发明REST并最终导致“各行其道”?那时他的文章收到了各种答复,比如一个答复者说他在一个WebSockets公司工作,所以他的观点可能不是客观的,他提到:

REST和WebSocket的通讯看起来是分布式计算管道的两种类型。REST是那个老学校,坐在HTTP的顶上,同步风格的web调用。WebSocket是新的,坐在HTTP旁边的,通常是异步的web通信。恕我直言,长期看来,WebSocket将显著地降低WAN计算中对于REST的需求。使用WebSocket,过去几十年中我们所熟知和喜爱的所有协议将被扩展,并且不会出现在使用HTTP的情况下的笨拙和低效。

还有另外一个提到:

我认为REST陷入了传统的请求/响应模式。而WebSocket满足了Comet和长轮询的场景,通讯管道在多次通讯过程中并不关闭。同时,到WS初始的握手仍然由HTTP发起,所以实际上他们并非互斥的。我还认为WS协议的目的就在于摆脱HTTP头中那些令人讨厌的东西,因为它们冗长并且只增加了负载。

然而,在同意REST和WebSockets能并且应该共存的同时,一些评论者完全不同意REST-over-WebSockets规范的概念。一个说道:

如果你把REST看作字段式的,具有地址的资源,那么这在双向通讯中无法工作。你无法期待资源会初始化对话,WebSocket会改变Web,但不是作为一个REST风格的通信协议。

而另一个更详细地描述了自己的观点:

WebSockets就像两个人的对话,是完全双工的,因此双方都可以同时说话,而且双方在说话的时候也都必须同时保持监听。REST是无状态和同步的,只能处理请求->响应。要获得自发的服务器向客户端的通信,你必须扩展REST的概念。我看到过一个使用WebSocket实现了REST的库,但它也只能对于那些已经有了RESTful API并且想要获得低开支的好处,以使单个连接即可满足通信要求而不用重构代码的应用有好处。

REST社区也有一些人,比如 Jim Webber,认为WebSockets 对web来说不是好的选择

Jim Webber tweet

在WebSockets即将成为标准之际,它正在被广泛支持并使用于浏览器、手机,想要弄清楚它们对正在使用REST和HTTP的开发者会产生多大的影响是很有趣的,亦或它们针对的是不同的开发者团体?更糟的是,一些人相信我们正在冒着“破坏Web网络”的危险?

英文原文:WebSockets versus REST?

 

via http://www.oschina.net/translate/websockets-rest 

 



最新评论


返回顶部

分享到微信

打开微信,点击顶部的“╋”,
使用“扫一扫”将网页分享至微信。