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 帶來好處：
隨著 WebSockets 幾乎已經成為了一種標準，而且被瀏覽器、移動設備以及云所支持和使用，我們倒很有興趣來了解一下這會對那些當前使用 REST 和 HTTP 的開發者帶來多大影響，或者會被一個不同的開發者團體所接受？更糟的是，是否像某些人所堅信的那樣，我們已經處在“Web 正在被破壞”的危險之中？
查看英文原文：WebSockets versus REST?