ハイパーメディアを意識したクライアントとサービスを作成するためのフレームワークである Restfulieプロジェクトのリリースに関して11月にInfoQで取り上げた。また、創設者であるGuilherme Silviera氏によるJAX-RS実装のひとつであるRESTeasyとRestfulieの比較を先日とりあげた。その中で、RESTeasyは(もしくはJAX-RSさえ)、RESTfulアプリケーションを構築するための適切な基盤であるのだろうかと疑問を投げかけている。この記事は、コミュニティの中で議論を引き起こした。そこで我々は、Guilherme氏にインタビューを行い、論拠の整理を行った。
Infoq: こんにちは、Guilhermeさん。まずはじめに、なぜRestfulieを開発することになったか、その理由を説明してもらえませんか。
Guilherme氏: Jim Webber氏とSavas Parastatidis氏、Ian Robinson氏の３氏は、2010年の初頭にWebを基盤として利用することに関する本を出版します。その本を読んで、私はいかにハイパーメディアがRESTに適合するかを、ようやく理解することができたのです。Roy氏とSubbu Allamaraju氏の著作とJAX-RSの実装を見直してみて、JAX-RSではWebのHTTPとURIの部分は強調されているけれども、ハイパーメディアの性質についてはそうでもないと私は気がつきました(ちょうど、Richardson氏がqcon 2008で指摘したようにです)。ですので、Restfulieでは、ハイパーメディアにまず焦点をあてて、HTTPとURIはその次の優先順位にしたのです。
InfoQ: Restfulieのコミュニティはどれくらいの大きさなのですか。
Guilherme氏: Restfulieは、まだ誕生して間もないですので、現在のところコミュニティは小さなものです。しかし、私が好きな方々から、前向きなコメントをもらっています。たくさんの人の貢献でRubyバージョンはリリースされ、私たちはユーザからのフィードバックを集めています。Jim Webber氏は理論的な問題と実際上の問題の両面で我々を支援してくれています。Rails 3の関係者であるJose Valim氏とYehuda Katz氏によるフィードバックによって私たちは改善を行うことができました。Rubyコミュニティで有名なBrian Guthrie氏とFabio Akita氏も、コードとDSLのアイデアの両面で貢献してくれました。
InfoQ: あなたの記事はRestfulie対JAX-RSに関するものでしたので、標準に関してどう考えておられるかお聞かせいただけませんか。
Guilherme氏: いい質問ですね。うまくリリースされたJSRというものを考えるとき、Hibernate/JPAが常に頭にうかびます。JCPがORMに関してはじめに取り組んだのは、JDOです。そしてJDOは、多くの理由からHibernateのようには成功しなかったのです。こうなってしまった主な原因は、トップダウンアプローチにあると私は思います。JDOの場合、既に成功しているソリューションのAPIを参考にすることなしに、新しいJSRを策定しようとしたのです。Gavin King氏がをJSR 220をリードし、JPA 1となりました。JPA 2では、Hibernateの実証済みの機能がさらに取り入れられており、その中でも特筆すべきなのはCriteria APIです。すなわち、次の質問が重要なのです。開発者はHiberneteのスタイルであるStringを使ったCriteriaを利用するか、タイプセーフを実現するために新しくつくられたStaticMetaModelアプローチを使うか、どちらかということです。
コミッティ主導の標準と、成功したAPIからアイデアを得てJSRになったその他のもの(Hibernate/JPAやおそらくSeam/CDI(以前のWebBeans)といったもの)とで何が起こってきたかを皆さんはご覧になってきたことでしょう。標準はとても重要です。しかし私たちはそろそろ失敗から学ぶべき時期なのです。JPAとCDIの場合、JBossは既に存在し、広く受け入れられたAPIから得られた経験をJSRに盛り込みました。InfoQは、このことを強調したRod Johnson氏のプレゼンテーションを先頃掲載しました。「Rod Johnson氏は ... コミッティ主導の標準などの失敗から学べる教訓を示し ... 将来に同様の失敗を繰り返さないために準備をしています。」
Restfulieに関して言えば、記事に対するフィードバックを受けとりました。中でもJim Webber氏が最初にブログで次のように反応してくれました。「悪いのは、RESTEasy (もしくはJerseyやCXF)ではないのです。目的がばらばらでRESTに対する理解度もまちまちなコミッティ主導のプロセスでは、JAX-RSという最大公約数的なものしか作れないのです。」RESTの世界はもっと注意深く考えられるべきものなのです。JAX-RSの仕様は、HTTPとURIに非常に重きを置いている一方、ハイパーメディアによる制約に関しては手がつけられていない部分が多く残っています。仕様がHTTPとURIのサポートに偏っているため、ほかのJAX-RS実装は、ハイパーメディアに関連するほぼすべての部分を独自の方式で扱わざるえないのです。Roy氏が指摘したようにHTTPはそれ自体APIなのです。ですから、露骨な言い方をすれば、HTTPを利用して構築した他の仕様などあるべきではないのです。
InfoQ: 独自のRESTfulフレームワークを構築するのではなく、JAX-RSプロジェクトのどれかひとつに貢献しようとはお考えにならなかったのですか。
Guilherme氏: RestfulieはRails環境で生まれたので、着想段階では、そんなこと考えもしませんでした。教育を行う企業で働いているので、私たちは一番最初に一番重要なアイデアを提示することが学習者にとってどれだけ大事かを知っています。私たちは、ドキュメントをベースとするJAX-RS(とその実装)の標準化の道は通りません。JAX-RSでは、URIとHTTPに主眼をおいて、ハイパーメディアをずっとあとに考えていますが、私たちは、彼らの考えをハイパーメディアの重要性に向けさせて、HTTPとURIはその後にというようにしたいのです。
まずはハイパーメディアに集中すると、URIとHTTPの必要性が自然とみえてきます。私たちがクライアントから受け取ったフィードバックは、彼らがRESTのハイパーメディアの側面を利用しているといったものでした。したがってクライアントはハイパーメディアのアプローチの利点を理解してるように思われます。JavaバージョンとそれをどのようにJAX-RSの標準と関連付けるかは、次の質問になるかと思います。
InfoQ: Restfulieの次の展開を教えてください。
Guilherme氏: 私たちはハイパーメディアの制約に焦点をあてたJavaバージョン(vraptorとhibernate)をリリースしたばかりです。vraptor 3がリリースされたとき、私たちはまだJAX-RS実装にすべきなのかどうかはっきりしていませんでした。標準化は重要です。そしてそれと同様にマーケットにあたらしいアイデアを提供する他のフレームワークも重要なのです。その役割が、現時点ではRestfulie(そしてvraptor)にあっていると信じています。もしシステムを作る上でよりよい方法がみつかったなら、将来的にこの方針は変わるかもしれません。ハイパーメディアに焦点をあてるという方針を失わない限り、他の実装と力をあわせるということもありえます。
Rails 2バージョンのリファクタリング、Rails 3と.NETバージョンの実装、そしてクライアント・サイドでの数多くのHTTPヘッダやレスポンス・コードのサポート(サーバ・サイドでは既にサポートしています)。Restfulieのクライアント側は、私をもっとも驚かせてくれるもののひとつです。 単にHTTPをシリアライズしてくれるツール(例えばJAXB＋httpclientやその他のもの)と違い、デフォルトの動的URIバインディングやステートの遷移といったすばらしい機能を数多くもっています。
InfoQ: 本日はお時間をいただき、ありがとうございました。
Guilherme氏: どういたしまして。