この数年、WebSocketの人気が高まり、利用可能になってきた。昨年末にはW3C勧告候補となり、標準化に向けてまた一歩前進した。OracleなどもJava Enterprise Editionの次バージョンに向けて、WebSocket関連 (JSR 356) の標準化を開始するようリクエストしたところだ。Chrome、Firefox、Safari、IEといったメジャーなブラウザはみな、すでにWebSocketのいずれかのリビジョンをサポートしており、最終的には標準化されたものを採用することになるだろう。近いうちに、WebSocketはWebになくてはならないものになりそうだ。しかし、WebSocketがWebのアーキテクチャスタイルであるRESTにどのようにフィットするのか、あるいはフィットするのか否か、確信が持てないでいる開発者もいる。Nathan Evans氏のように、WebSoketはRESTに暗雲を投げかけるだろうとまで言っている人もいる。
標準について詳しく調べて、オンラインでの議論に目を通したところ、私はますますこの標準はRESTfulウェブサービスから大きなマインドシェアを奪うだろうと確信を深めています。私が言っているのは、製品開発の現場で、だれかがこんな風に尋ねるような段階にきているということです。
「ねえ、今度のプロジェクトにはWebSocketを使うべきかな、それともRESTを使うべきかな?」
この1、2年のうちに、WebSocketはRESTfulウェブサービスの成長、少なくとも今のような成長を阻害しはじめると思います。
この記事でNathan氏は、RESTを使った自分の経験から、RESTは一部の人が言っているような「銀の弾丸」ではないと思っているが、WebSocketもまた完全ではないことを認めている。彼はなぜWebSocketがRESTにとって脅威なのか、いくつも理由を挙げている。ここにはテキストベースプロトコルによる「出来の悪い」RESTフレームワークへの依存といったものも含まれる。WebSocketがRESTよりも優れている大きなポイントのひとつには、双方向のインタラクションがある。
WebSocketがもたらす真の双方向性は、HTTP由来のプロトコルで初めてのものです。これはSOAPもRESTも備えていない特徴です。Comet/プッシュ/ロングポーリングといったものはエミュレーションにすぎず、非効率なものでした。双方向性は本質的にすぐれた特性であり、望むならリモートデスクトップやVNCといったリアルタイムTCPプロトコルをWebSocket上でトンネリングすることもできます。
WebSocketの効用はREST(HTTP)にまさり、開発者はRESTからWebSocketへと移行するだろうとNathan氏は考えている。
ビジュアル中心でクロスプラットフォーム互換性をもったWebサービスが必要なプロジェクトでは、これまで通りRESTが第一選択になるでしょう。こうした要件のないプロジェクトでは、代わりにWebSocketが選ばれるでしょう。そして、その上にJSONを流したり、専用プロトコルを使うようになると思います。 [...] たとえ競合したとしても、RESTとWebSocketは実際のところ共存できるのはよいところです。どちらもHTTPの基盤の上に成り立っており、互いに補い合うと思います。
しかしながら、「WebSockets or/versus REST」という疑問を取り上げているのはNathan氏だけではない。たとえばShay Bannon氏は2010年頃、WebSocketにもRESTの原則を適用できると考えた。
まず、どうやってURIを表現しますか? 次に、どうやってHTTPメソッド (GET、PUT、POST、…)を表現しますか?最後に、どうやってHTTP uri パラメータやHTTPヘッダを表現しますか?ある種のスキーマをテキスト文字列であるコンテントに構築するのが解決策となるでしょう。“uri”フィールドや“params”などを持つJSON文字列といったものです。しかし、これには厄介なところがあります。なぜならHTTPでは、ボディをパースしなくても、ヘッダやパラメータだけを使った非常にシンプルなゲートウェイが作れるためです。
彼は、なぜWebSocketにはURIやヘッダといった概念がないのだろうか、あちこちでRESTを再発明して「バラバラなやり方」ができる前にREST-over-WebSocket仕様のニーズはあるのだろうかと考えた。このとき、彼はこの記事に対して相反するレスポンスを得た。たとえば、ある読者は、自分はWebSocket関連企業で働いているので客観的ではないかもしれないがと断りつつ、次のように述べた。
RESTやWebSocketというのは、分散コンピューティングのための異なる種類の配管のようなものだと思っています。RESTは伝統的な同期型のWeb RPCで、HTTP上にあります。WebSocketはそれよりも新しくて、通常非同期型のWebコミュニケーションで、HTTPの隣りにあります。私は長期的に見て、WebSocketはWANコンピューティングにおけるRESTの必要性を劇的に減らしていくと思っています。WebSocketを使うと、私たちがよく知っている数十年間愛用してきたプロトコルはみな、不恰好なパフォーマンスのわるいHTTPマッピングをすることなく、Web上に拡張できるのです。
またある読者はこう語っている。
私の見解では、RESTは伝統的な要求/応答パラダイムです。これに対して、WebSocketはComet/ロングポーリングのシナリオを満たすものです。通信ラインは複数のコミュニケーションサイクルのためにオープンしっぱなしになります。またWebSocketに対する初期ハンドシェイクは依然としてHTTPで始まります。そのため実際のところ、相互排他ではありません。私はまたWebSocketプロトコルの大事なところは、HTTPヘッダの出来の悪さをなくすことだと思っていました。HTTPヘッダは冗長で、ペイロードサイズを大きくするだけだからです。
RESTとWebSocketは共存できるし、そうすべきだという意見がある一方、REST-over-WebSocket仕様を作るという考えにはまったく同意できないという人もいた。
もし複雑なアドレッシング可能なオブジェクト(もしくはリソース)による置き場所としてRESTを考えているのなら、これは実際のところ双方向コミュニケーションとして機能しません。会話を開始するためのリソースといったものを期待してはいけないのです。WebSocketは(もし立ち上がれば)Webを変革するものですが、それはRESTスタイルの通信のためのプロトコルとしてではありません。
また、さらに詳しく次のような意見もあった。
WebSocketはADDによる2者間通信のようなものです。全二重であり、双方が同時に話すことができ、双方とも話しながら耳を傾け続ける必要があります。RESTはステートレスで同期型であり、リクエスト->レスポンスだけを扱います。もともと推奨されないサーバ->クライアント通信の効果を得るには、RESTのコンセプトを拡張する必要があるでしょう。WebSocketでRESTを実装したライブラリもありますが、これが有用なのは、すでにRESTful APIがあり、コードのリファクタリングなしにシングルコネクションによるオーバヘッド削減効果を得たいアプリケーションだけでしょう。
RESTコミュニティには、Jim Webber氏のように、WebSocketはWebにふさわしくないと考えている人もいる。
WebSocketの利用が間もなく標準となって、モバイルやクラウドでもサポートされ使われるようになると、現在RESTやHTTPを使っている開発者にどんなインパクトを与えるだろうか、あるいは別のセグメントの開発者たちの注意を引きつけるのだろうか?