今月はじめに開かれたJBoss Worldにおいて、JBossが正式に新しいREST-*の構想を発表した。
REST-*は以下の違いを示すことで、WS-*と明確に区別しようとしている。
WS-*は優れた仕様の集合であり、ネットワーク上にミドルウェアサービスを実装するための様々なプロトコルとエンベロープのフォーマットを定義しています。CORBAと比べると大いに改善されている一方で、いくつか欠点もあります。この欠点はREST-*コミュニティが修正したいと願っているものでもあり、それには以下のものがあります。
WS-*はHTTPを活用していない WS-*はHTTPをトランスポート・プロトコルとして使用しています。また、WS-*サービスはHTTPを、主に接続をセットアップする機構として使用しており、ウェブをここまで成功させた豊富で実績のある機能に目を向けていません。（中略）私たちはRESTfulな原則に焦点を当てているので、この組織が提示する仕様はHTTPプロトコルをフルに活用しますし、その技術を再発明しようとはしません。
WS-*は参入にあたって敷居が高い WS-*のスタックは実装が難しく、それを使うにはクライアントにおいてもサーバにおいても複雑なスタックを必要とします。（中略）私たちは一連の仕様によって、この参入の障壁を最小化したいと考えています。
WS-*はエンベロープのフォーマットを必要とする WS-*のスタックはSOAPを必要とします。これはWS-*がメッセージを送信する際に用いるエンベロープのフォーマットです。（中略）HTTPメッセージフォーマットで十分です。これはシンプルかつ堅牢で、柔軟性に富んでいるのです。
この構想のアーキテクチャ上の目標は以下の通りである。
低い参入障壁 この仕様を用いるクライアントにとって、敷居は低くなければなりません。仕様を使うのに、ライブラリや大量のソフトウェアスタックをインストールする必要があってはいけないのです。
周辺的なケースは拡張としなければならない メインの仕様を複雑化させる周辺的なケースは、分割されたサブ仕様にて定義しなければいけません。それぞれの拡張は階層上、メインの仕様の上に位置づけられるよう努めるべきです。
実践的REST 仕様はRESTfulな諸原則に従うよう努めなければなりませんが、純粋なREST原理主義者となってシンプルであることを犠牲にしてはいけません。よりシンプルなデザインを作るためにRESTのルールを曲げる必要がある時には、そうすべきです。
80/20ルール 各仕様はシンプルに保つべきです。（中略）各仕様はほとんどの一般的なユースケースのうち80%をカバーすべきです。周辺的なケースはメインの仕様に含めるべきではありません。
エンベロープ形式を避ける 可能な限りエンベロープ形式を避けなさい。（中略）エンベロープ形式はHTTPを拡張するよりもむしろ、HTTP上にトンネルを作ることを助長します。ほとんどの場合HTTPヘッダーは、リクエストやレスポンスもしくはリソースに関するメタデータを転送するのに十分なはずです。
データフォーマットは拡張として分離する 可能であれば、各仕様は新しいデータフォーマットを定義しようとするべきではありません。
発表によれば、JBossは完全に協調的なコミュニティを作ろうとしている。これはJBoss.orgのようなものであり、ベンダ主導によるベンダのためのものではない。描いているのはオープンソースのアプローチである。
（前略）新しいプロトコルを定義すること（中略）しかし、この努力すべてに関する主なポイントの１つは、RESTfulなやり方で（HTTPを用いる場合でもそうでない場合でも）物事を行うためのガイドラインとベストプラクティスをドキュメント化することです。そこにはセキュリティやマネジメントが含まれるかもしれません。
（ちなみに、Mark Little氏による上記の引用は前述したアーキテクチャ上の目標と既に矛盾している。新しいプロトコルと非HTTPのサポートが、ここでは暗示されているのだ。）
Little氏は以下のように述べている。
私たちが最終的に、あれこれを達成するための「標準的なやり方」へのリンクを集約したものになるのだとしたら、それもまた成果なのです。（中略）これが始まったのは、コミュニティが求めたからでした。同じ質問に行き当たりながらも、書籍やこの領域のエキスパート、その他のリソースといったさまざまなソースから明確な答えを得ることができませんでした。場合によっては、様々な異なる回答を得てきたのです。それは答えが存在しないということでしょうか？そんなことはありません。しかし、もしRESTを本当に理解している人々が何かについて合意できないとしたら、ただRESTを使用したいだけの人にとってはどんな希望があるというのでしょう。そこにREST-*が目的とするものがあります。コミュニティをつなぎ、明確なガイドラインを見いだすことで、回答が必要な時に誰もが参照できる場所を作ろうとしているのです。
しかし、この新しい構想はREST対WSという議論から距離をとろうとしている。
WS-*に対するRESTの恩恵は多くの記事、ブログ、メーリングリストを通じて議論されてきました。私たちはそれら全てを蒸し返そうとは思っていません。さらに情報が欲しければ、"REST vs. WS-*"とGoogleで検索して下さい。
このような比較は、WS*の機能について（きちんとした根拠に基づくことなく）一定程度言及することによって、効果的に行われている。例えば、WS*は重く、RESTは軽量であると言おうとするといった具合である。しかし実際には、どちらの標準も「手で」実装することができ、この場合は（HTTPだとすると）どちらもほぼ同じ量のコードを必要とする。これに対し、自動的なマーシャリング／アンマーシャリングとメッセージ・ルーティングが用いられた場合にも、コードの量はそれほど変わらない（例えば、非常に優れたフレームワークであるRestEasyは38個のjarを含んでいる）。もし、同じレベルの抽象度で比較したならば、必要とされるコードの量は大体同じなのだ。こういった例は枚挙に暇がない。
したがって、REST*の発表がインターネット上において少なからぬ反応を引き起こしたのは驚くべきことではない。Steve Jones氏の記事「REST-* 大人になってくれませんか」は、これについてうまく要約している。
「REST-*の努力は既に存在するものをドキュメント化するだけとなるかもしれない」と言う時に示唆されているのは、問題の一部にあるのが、多くの人がRESTが何であるのかを実際に知らず、高度なシステムを構築したり、組織間で相互に通信しようとする時におそらく苦労しているということなのです。この問題の一部はもちろん、アップフロントな契約とバリデーションをどこで行うのかという問題に関連するものです。しかし他にも、純粋にスノッブなもので、深淵な知識を持ちたいという欲望があるように見えるのです。
Jones氏はさらにこう続ける。
もしRESTがダモクレスの剣のようなもので、企業と世界のインテグレーションに関する課題を切り開くことができるとしたら、それをどうするのかをドキュメント化したり、どう開発すべきかをより明確にするためにいくつか標準を定めるのに、どんな問題があるでしょうか。最も重要なのは、（SAPやOracleのように）RESTインターフェイスを標準化された方法で作成し、他ベンダのソリューションがシンプルにそれを使えることです。そこで明らかになるのは、WADLが必要になるかどうか、あるいはAtomとAtomPubが本当に企業の全シナリオか、少なくとも重要なシナリオは全て網羅できるのかということです。（これはつまり、WS-TXのひどい部分に合わせるためにREST-TXを作るなということです。）
RESTもWSも現実世界の実装における存在意義がある。問題はどちらが優れているかではなく、むしろどうやって共存でき、どういう時に片方がより適切であるのかである。もう一つ重要なのは、比較はメリットに基づくべきであり、信念に基づくべきものではないということだ。たとえ信念がどれほど強くても、である。WS*は多くの便利な標準とパターンを生み出した。問題はそれをやり直したり、それらのパターンがRESTに適用できるかを調べることに意味があるのかどうかということである。