REST-*の発表とそれに対するコミュニティの反応をとりあげたInfoQのREST-*.orgに関する最近の記事は多くの反響を得た。フィードバックの結果として、REST-*にも 変更が加えられた。Infoqは、REST-*のリーダーであるBill Burke氏にインタビューを行い、さらに多くのことを学ぶ機会を持つことができた。
InfoQ: あなたのバックグラウンドについて、少しお話いただけませんか？
今は、Red HatのJBoss部門でフェローをやっています。過去には、クラスタリングやEJBコンテナ、AOPの実装や、アプリケーションサーバのカーネルの開発を行ってきました。現在は、RESTEasyプロジェクトのリーダーをやりながら、REST-*.orgを運営しています。そして、何冊かの本を書いています。2009年の11月にはJAX-RSに関する本がオライリーから出版されます。
InfoQ: RESTを魅せられるようになった経緯を教えてください。
分散システムを実装する有効な方法としてRESTを受け入れるまでに、しばらく時間がかかりました。JBossの同僚やもっと一般的にJavaコミュニティにRESTを啓蒙する際には、常に同様の困難が伴います。最初は、RESTをプラットフォームや言語をまたいだ真の相互運用性を実現するための単純で軽量な方法だと見ていました。より深く学ぶにつれ、RESTのアーキテクチャの原則は、相互運用性を超えて、アプリケーション開発者がサービスとアプリケーションの間のやりとりを疎にすることを助けてくれるということがわかりました。
InfoQ: 最後の点をもう少し詳しく説明していただけませんか。どのようにRESTが疎結合を推進してくれるのでしょうか。
主要な原理として、RESTfulなシステムはメディアタイプとそれらの間のハイパーリンクで動いているということがあると思います。クライアントは扱い方がわかっているデータ構造を求めることができるのです。返されたデータにはサーバーとやりとりするのに必要なすべての情報（ハイパーリンク）が含まれています。新機能が提供されると、新しいメディアタイプが追加のリンクを提供します。
私たちがREST-*.orgで作成している仕様もこのような方式で組み立てていきたいと考えています。ミドルウェア・サービスにインターフェースを定義する際には、APIを拡張するのに多くのエッジケースが常にあります。REST-*の中心の仕様で焦点を当てたい点は、コアとなるリソースとリンク関係の定義です。基本的に、私は新しいREST-*が仕様を作成しようとしている各ドメインのために新しいメディアタイプを定めるフレームワークとガイドラインを定義したいと考えいます。このやり方だと、次にコアモデルを修正する際に役に立ってくれるような異なったデータモデルを試してみる余地をコミュニティに残すことがでます。
InfoQ: JBoss Worldでのあなたの素晴らしいプレゼンテーションのなかで、SOAとROAを比較しようとしておられましたね。それについて、もう少し詳細にお聞かせ願えませんか。
私が一月頃にJBoss Worldでのプレゼンテーションを編集していたときに（私は様々なカンファレンスでこのプレゼンテーションを改善しながら使ってきました）、SOAガバナンスに関するAnne Thomas Manes氏による素晴らしいプレゼンテーションをInfoQで目にしたのです。そのなかで彼女は、SOAを組織に適用する際には制約が重要だと語っていました。制約がなければ、多くのサービスが組織内で利用可能になるにつれ、指数関数的にサービスの管理や統合、再利用が困難となっていきます。RESTは、分散インターフェースに制約を定義するものなのです。このように、疎結合にとって強力なツールなので、大きな組織で活用するのに適しています。HTTPプロトコルの汎用性と組み合わせることによって、真に軽量な相互運用性も得ることができます。
InfoQ: あなたはプレゼンテーションの多くで、RESTにとってのHTTPプロトコルの重要性について強調されています。不安定でコネクションレスのHTTPが主要なサービスのコミュニケーション媒体となるとお考えですか？
Roy氏が繰り返し力説しているとおり、RESTはHTTPに限定されていません。そうはいっても、現時点でHTTPにとってかわるような真に軽量でプラットフォーム非依存の普遍的なアプリケーション・プロトコルは存在しません。HTTPは新しい何かが登場するまでは働き続けなければならないのです。RESTエバンジェリストがいうように、Webはそれ自身非常にうまくいっているのです。
InfoQ: RESTの利点のひとつは、Webサービスの実装に比べて、とても軽量だということを、あなたは何度か論じてこられました。一方、たとえばJAX-RSのようなものを利用して抽象度を上げると、顕著に長大なものになってしまいます。たとえば、RESTEasyは38個のjarファイルとして提供されています。このような傾向は続いていき、RESTスタックのサイズがWSスタックのサイズに追いついていくとお考えですか？
RESTFulな環境で、HTTP呼び出しを行うことは、WS-*よりずっと軽量です。その主な理由は、WS-*がHTTPで単純にリクエストを送信するのに加え、エンベロープのフォーマットを必要とするという点です。言葉をかえると、WS-*は、HTTPの中に追加のプロトコルを通しているのです。このWS-*プロトコルはメディアタイプの定義に加えて、WSDLを使って定義される必要があります。RESTでは、メディアタイプだけを定義しておけばよいのです。操作や、メッセージのフォーマットは既に定義されているのです。
RESTスタックが大きくなり、サイズでWSスタックに追いつくとしても、アプリケーションを実装する面でも、スタックを提供するという面でも、複雑になりすぎる必要がないのです。RESTの疎結合で動的な性質は、HTTPのコンテント交換と組み合わさって、基本となるインタラクションとメディアタイプを単純にします。しかし新しいメディアタイプとリンク関係を作成することで、より複雑なプロトコルと組み合わせることもできるのです。
しかし、RESTEasyに関して公平な視点から見てみると、通常のJavaプロジェクトは、サーブレットコンテナやロギングAPI、HTTPクライアントライブラリなどに対して依存しているものですが、RESTEasyのコアの部分は数個の依存関係があるだけなのです。残りのjarファイルは、他のコンポーネントモデル(例えば、SpringやGuice、EJBなど)とRESTEasyの統合や、JSON、XML、マルチパート、AtomやXOPといったフォーマットへの対応をJettison、Jackson、James、Abdera、JAXBといったサードパーティのライブラリを利用して実現しています。素のサーブレットコンテナをつかってRESTfulなサービスを開発することができないなんてことはありません。しかしその時にも、私たちが同梱しているサードパーティのライブラリを利用するに違いありません。
私たちはMavenへの対応を推し進めているので、必要な依存ライブラリを選択してもってくることができます。
InfoQ: 多くの人が事前のコントラクトと早い段階での検証がサービスの相互運用性では重要だと議論しています。このことに対するRESTの回答はなんなんでしょうか。WADLですか？
いいえ。私は、WSDL相当のものが必要だとは思いません。RESTでは、やりとりはクライアントとサーバーの間で交換されるメディアタイプとリンク関係で定義されています。言葉を換えるとメディアタイプの交換がコントラクトなのです。
InfoQ: 多くの人がRESTの主要な利点の一つはメソッドの数が限られていることだと論じています。つまり、要求されたアクションがサービスのペイロードのなかに記述されることがしばしばあるということです。4つというのは、メソッドの数として最適だとお考えですか？
初めに断っておきますが、RESTではアクションは、ペイロードに組み込まれるべきではありません。クライアントはアクションをステートとして設計しなければなりません。
しかし、想像するに、RESTの画一的なインターフェースの制約について話されているのではないでしょうか。4つのメソッドしかもたないSQLで、複雑なインタラクションやアプリケーションを設計することができます。しかし、あなたの質問に答えるとPUT、POST、GET、DELETEで十分かということでしょう。私は大半のシステムにとっては十分だと考えます。サービス定義を利用するというオプションは確かにありえるでしょう。リソース同士を関係づけたいだけであれば、LINKとUNLINKがおもしろいユースケースとなるでしょう。
InfoQ: では、REST-*の目的はなんですか。
私たちのゴールは、Workflowエンジンやビジネス・プロセス管理、メッセージ・ソリューション、そしてトランザクション・マネージャさえ含んだ伝統的なミドルウェアサービスがRESTfulなアーキテクチャとアプリケーションに適合することを示すことです。これらのサービスのインターフェースを定義する仕様とガイドラインの組を定義することによって、それを実現しようとしています。私たちがやるつもりのないことのひとつは、RESTや、一般的なRESTfulのガイドラインの定義です。これは、RESTコミュニティの重鎮たちにとっておくのがよいでしょう。私たちは、企業向けのミドルウェアに集中します。なぜなら、その分野は、私たちが専門としている分野だからです。
InfoQ: あなたが企業向け分散コンピューティングでやる必要のあることは、全て既にRESTとHTTPに存在していると考えている人もRESTコミュニティの中にはいます。では、なぜREST-*が必要なのでしょうか。
RESTの多くは、Human Webを例にして説明されています。Human Webとは、ブラウザとブラウザを使っている人間を意味します。マシンがクライアントの場合に、RESTアーキテクチャとどうやりとりするかは、私の考えでは初期段階にあります。企業のITは、分散アプリケーションを構築するために特定のミドルウェアアプリケーション群を使ってきました。RESTの利点として、伝統的な企業向けIT開発がミドルウェアとやりとりする方法を考え直すきっかけを与えてくれます。これが、REST-*.orgが解決しようとしていることなのです。最終的には、RESTはミドルウェアの死となるかもしれません。しかし、私が考えるに、答えはその間のどこかにあると思います。
InfoQ: REST-*は、将来的にどのように発展していくとお考えですか？
最初に、RESTfulなインターフェースを作成する一連のサービスの定義から始めます。それぞれのサービスは特定の問題を解決します。できることなら、ここから、ドメインをまたがって利用可能なセキュリティのような一連の一般的なガイドラインを導きだしたいと考えています。おおやけにするのに十分と思えるほどに形がととのった段階で、それらをIETFやW3Cといった標準化団体に提出したいと考えています。
InfoQ: 参加するにはどのような手順をとればよいのでしょうか。例えば、個人も参加できるものなのでしょうか。それともベンダーだけなのでしょうか。
REST-*は仕様とガイドラインを策定することを目的とした一連のオープンソースプロジェクトです。私たちが公開したものは、すべてオープンソースのライセンスが適用されます。現時点では、ASL 2.0を利用していますが、他のライセンスに変更することもやぶさかではありません。
REST-*.orgをオープンソース・プロジェクトとして運営しているので、私たちがやろうとしていることは、すべて公開の場で行われるのです。どんな個人や組織も参加できます。メーリングリストに登録しさえすればよいのです。私たちは、外部の会社や個人に仕様策定の一部を担っていただきたいと望んでいます。Red Hatがこの取り組みの立ち上げを行っていますが、Red Hatが舵取り役になるのは適切ではないと考えています。
InfoQ: JBossの中での、RESTとREST-*の未来を教えてください。
管理とツールのための分散インターフェースを定義するのに伝統的な方法を使うのでは、脆すぎて、年を経て製品が進化するにつれて管理をしづらくなることがわかってきました。多くのエンジニアがより良い方法を探していたのです。私は、RESTがこれらの問題のうちいくつかを解決してくれると考えています。私たちは既に、RESTをいくつかの製品の管理インターフェースに適用し、恩恵を受けています。私たちのプロジェクトや製品の設定方法やプロビジョニングの方法によい影響を与えたいと考えています。
REST-*に関して言えば、RESTEasyのオープンソースプロジェクトで、仕様の初期実装をプロトタイプしようとしています。これによって、私たちは、アイデアをアクションに結びつけることで価値のあるフィードバックループを得ることができます。
InfoQ: 最後に一言お願いいたします。
ここ数年、分散コンピューティングは同一の古いアイデア、パターン、テクノロジーを際限なくパッケージを詰め替えて提供してきました。RESTによって、ついに私は分散コンピューティングが進化し先に進み始めたと感じることができるようになりました。RESTによって、世界の飢餓を解消することはできないでしょうが、ソフトウェア・エンジニアリングを実践する新しい視点を必ず与えてくれます。