WebSockets与REST之争？

     <div id="news_body">     <p>        在过去的几年中，<a href="/misc/goto?guid=4958331432111311207">WebSockets</a> 变得越来越流行并积累了不少用户。去年年底，WebSockets 成为了 <a href="/misc/goto?guid=4958185768467117154">W3C 的推荐候选</a>，这使得其向标准更迈进了一步。Oracle 等其他厂商最近也提交了申请，来启动在 Java 企业版的下一个版本中引入 WebSockets（<a href="/misc/goto?guid=4958328739870615939">JSR 356</a>）的标准流程工作。绝大部分的主流浏览器，如 Chrome、Firefox、Safari 和 IE，都支持某个 WebSockets 修正本，并最终会采用最后成形的标准。在<a href="/misc/goto?guid=4958331434383219768">较短时间内</a>，<a href="/misc/goto?guid=4958331435196580133">WebSockets 几乎已经</a>成为了 <a href="/misc/goto?guid=4958331436002942125">Web 不可分割的一部分</a>。尽管如此，仍有一些开发者对 WebSockets 将会如何或者是否能够融入到 Web 架构风格：REST 持保留意见。有一些人，如 Nathan Evans，针对这一问题则<a href="/misc/goto?guid=4958331436799754675">表示</a>WebSockets 会使得 REST 相形见绌：</p>     <blockquote>      在仔细研读了 WebSockets 标准并吸收了各种相关的在线讨论后，我越来越清楚地了解到该标准打算窃取 RESTful web 服务所分享的绝大部分想法。我想说的是，将来在产品开发的某个阶段，一定会有人提出这么一个问题：      <p>"好吧伙计们，在这个项目中我们是应该使用 WebSockets 还是 REST？"</p>      <p>我预计 WebSocketes 将在一到两年内，开始阻碍 RESTful web 服务的发展——至少依目前的形势来看是这样的。</p>     </blockquote>     <p>        Nathan 在其文章中认为就他使用 REST 的经验来看，其实 REST 并不像有些人描绘的那样是所谓的“杀手锏”，当然了在他看来 WebSockets 也不尽完美。他随后罗列了几个为何 WebSockets 会成为 REST 威胁的原因，如 REST 框架依赖于标准较低的基于文本的协议。相对于 REST，WebSockets 提供了包括双向交互在内的一些较为重要的利好：</p>     <blockquote>      WebSockets 所提供的真正的双向交互能力对任何衍生于 HTTP 的协议来说，都是前所未有的。这种能力既不被 SOAP 也不被 REST 所拥有。而 Comet/推（push）/长轮询（long-polling）也只能模拟，而且效率并不高。双向交互能力从根本上说是相当好的，只要你愿意，你可以在 WebSocket 之上的远程桌面或 VNC 开通一个实时 TCP 协议通道。     </blockquote>     <p>        Nathan 坚信 WebSockets 带来的诸多好处远超 REST（HTTP）所能提供的，开发人员终将会选择转移到 WebSockets 上来。</p>     <blockquote>      对那些需要较高可视性且跨平台的可交互 web 服务的项目来说，REST 可能还将是其默认选项。而对于没有上述要求的项目而言，WebSockets 将有机会取而代之，运行在其之上的要么是 JSON，要么使用自定义的端协议。[……]尽管两者是竞争关系，但好在 REST 和 WebSockets 其实可以相互共存。事实上，由于它们都是在 HTTP 基础之上衍生的，所以两者是可以兼容的。     </blockquote>     <p>        然而，Nathan 不是唯一一个抛出“使用 WebSockets 还是 REST”这类问题的人。比如，<a href="/misc/goto?guid=4958331437597792645">Shay Bannon</a> 早在 2010 年就提出是否有可能在使用 WebSockets 时利用 REST 的一些原则：</p>     <blockquote>      首先要搞清楚的是，你如何来描述一个 URI？其次，如何描述 HTTP 方法（GET、PUT、POST 等）？最后，如何描述 HTTP URI 参数和消息头？似乎可以通过往消息内容（文本字符串）中构建某些模式（schema）的方法来解决。就像一个包含“uri”、“params”等域的 JSON 字符串那样。这样想就太复杂了，因为使用 HTTP，你可以创建一个非常简单的防火墙，只简单利用消息头或参数，而无需解析消息体……     </blockquote>     <p>        他想知道为何 WebSockets 没有 URI 或消息头的概念，这样看来，在大家重新改造 REST 并导致所谓的“非统一风格”之前，是否需要一个在 WebSockets 之上的 REST 规范？那个时候他收到了很多人对此文章的回应。比如，其中一个声称自己之前在一家 WebSockets 公司工作的人（所以其观点可能不太客观）回复道：</p>     <blockquote>      REST 和 WebSocket 通信看起来是两种不同的分布式计算风格。REST 就像传统派，在 HTTP 之上，同步的 web rpc 风格。WebSockets 则像新兴派，是 HTTP 的延伸，通常是异步的 web 通信风格。恕我直言，长远来看，WebSocket 将会极大的减少对 WAN 计算的 REST 需求。使用 WebSocket，那些在过去几十年中我们所熟知和喜爱的协议都可以在 web 上得以扩展，而无需担心映射到 HTTP 上的笨拙和性能短板。     </blockquote>     <p>        另外也有人回复道：</p>     <blockquote>      我的想法是 REST 引入了传统的请求/应答范例。相反，WebSockets 迎合了 comet/长轮询的场景，其通信范围可以在几个通信周期中保持开放。并且，WS 最初的握手仍然发生于 HTTP，所以实际上，它们并不相互排斥。我也认为 WS 协议的要点在于摆脱 HTTP 消息头的鬼把戏，因为它已经变得冗余，只会凭添消息负载。     </blockquote>     <p>        然而，虽然基本达成 REST 和 WebSockets 能够也应该共存的共识，但一些留言者完全不认同关于在 WebSockets 之上的 REST 的概念，其中有人谈到：</p>     <blockquote>      如果你以 Fielding 的观点来考虑 REST，将其作为一种可定位对象（或资源）的 web，那么这在双重通信格式上是行不通的。你不能指望资源能自己发起会话。WebSockets 将会转换 web（如果它们发起的话），但不是作为针对 REST 风格通信的一种协议。     </blockquote>     <p>        还有人给出了该观点的更深细节分析：</p>     <blockquote>      WebSockets 就像用 ADD 通话的两个人。完全是双向的，两边都可以同时说话，在对方讲话时，两边也都要拿起自己的听筒。REST 是无状态以及同步的，只处理请求->回应。你只能自己扩展 REST 的概念以期得到服务器（主动发起）->客户端通信的利好。我可以看到 WebSockets 中存在一个实现 REST 的库，但这只对已经拥有 RESTful API，并想得到削减开销的利好（一个连接即可，无需重构其代码）的应用有用。     </blockquote>     <p>        当然了，在 REST 社区也存在一些人，<a href="/misc/goto?guid=4958331438397161875">比如 Jim Webber</a>，他们坚信 WebSockets<a href="/misc/goto?guid=4958331439196715781">不会给 web 带来好处</a>：</p>     <p style="text-align:center;"><img style="width:534px;height:309px;" alt="WebSockets与REST之争？" src="https://simg.open-open.com/show/94ce4e2d3ab9e11047732991c20faf4e.jpg" /></p>     <p>        随着 WebSockets 几乎已经成为了一种标准，而且被浏览器、<a href="/misc/goto?guid=4958331440001233335">移动设备</a>以及<a href="/misc/goto?guid=4958331440799286969">云</a>所支持和使用，我们倒很有兴趣来了解一下这会对那些当前使用 REST 和 HTTP 的开发者带来多大影响，或者会被一个不同的开发者团体所接受？更糟的是，是否像某些人所坚信的那样，我们已经处在“Web 正在被破坏”的危险之中？</p>     <p>        <strong>查看英文原文：</strong><a href="/misc/goto?guid=4958331441592338774">WebSockets versus REST?</a></p>     <div id="come_from">      来自:      <a id="link_source2" href="/misc/goto?guid=4958331442388127128" target="_blank">InfoQ</a>     </div>    </div>