过去的几年，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来说不是好的选择。

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

英文原文：WebSockets versus REST?

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