WebSockets与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?

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

在过去的几年中,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和开源项目等。

Advertisements
This entry was posted in Achitecture, SOA. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s