在过去的几年中， 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带来好处：
随着WebSockets几乎已经成为了一种标准，而且被浏览器、 移动设备以及 云所支持和使用，我们倒很有兴趣来了解一下这会对那些当前使用REST和HTTP的开发者带来多大影响，或者会被一个不同的开发者团体所接受？更糟的是，是否像某些人所坚信的那样，我们已经处在“Web正在被破坏”的危险之中？
查看英文原文： WebSockets versus REST?
译者 吴宇 关注Java EE，感兴趣的技术领域包括软件架构、SOA、ESB和开源项目等。