RESTfulな(リンク)アプリケーションを作成するためのJavaフレームワーク、Restletは先日、2007年4月以来のメジャーリリースとなる1.1.0がリリースされ、新段階に入った。
Noelios Technologies社のウェブログ(リンク)で詳しく説明されているように、リリース1.1.0には多数の重要な変更がある。
- 部分的ダウンロードや再開可能なアップロード、コンテンツの完全性検証といった、広くて深いHTTPサポート。
- 業界随一のWADL仕様のサポートにより、REST APIのドキュメンテーションを自動的かつ常時同期させておくことが可能。WADL文書はXMLで生成するか、あるいはYahoo!で人気のスタイルシートを使って即座にHTMLに変換可能。
- アノテーション指向のアプローチを好む人々のために用意された、新しいJAX-RS 1.0仕様の実装では先がけ的存在であり、実装の完全度も最高。
- 新しいRestlet-GWTモジュールを提供し、クライアント側のRestlet APIを評判のGoogle Web Toolkit 1.5 JavaScriptプラットフォームにポートすることにより、Webブラウザから直接RESTfulなアプリケーションを呼び出し可能。
- 新しい機能拡張により、JAXB 2.1、JiBX 1.1、Spring 2.5、OAuth、OSGi、Oracle XDB、SSL技術との統合が容易。
- Atom配信XMLフォーマットおよびAtom出版プロトコル向けのサポートを改善。今ではフォーマット化とパースの両方を利用可能。
- JavaMailベースの新しいPOP3コネクタでRESTfullに遠隔地のメールボックスにアクセス。
- 新しいGrizzly HTTPサーバーコネクタは、Restlet APIでNIOサポートを完全活用するものとしては初めてのものであり、新しいレベルのスケーラビリティとパフォーマンスをもたらす。
- HTTPクライアントとサーバーの新しい内部コネクタが開発段階を単純化し（コンフィギュレーション不要）、非常に小さなデプロイメント・フットプリントが可能に。
RestletフレームワークはあらゆるJavaサーブレットコンテナ内から（RestletServletを介して）、もしくはスタンドアロンのJavaアプリケーションとして起動できるため、デプロイメントとコンフィギュレーションでは多数のオプションが利用可能になる。
Restlet 1.1に付属する前述のNIO HTTP サーバーコネクタは、RestletのスタンドアロンJavaバージョンを対象としており、GlassFishで(リンク)使われているGrizzly NIOフレームワーク(リンク)に基づいている。
先月リリースされたJSR-311(リンク)は、JAX-RS 1.0仕様を定義している。上で明らかにしたように、Restletはこの仕様をサポートしており、Restlet開発リーダーのJérome Louvel氏はJSRの専門家グループの一員を務めた。
InfoQは今回のリリースについてRestletプロジェクトのリーダー、Jérôme Louvel氏と話す機会を得た。まず、JSR 311のサポートについて尋ねた。
私たちはJSR 311の専門家グループの一員として、スペックリーダーに重要なフィードバックを提供できました。専門家グループの取り組みの間、Restlet APIは刺激を与える重要な供給源としても機能しました。Java向けとしては初のRESTフレームワークを提供した私たちには長い経験があり（パブリック版のリリースは2005年末）、 RestletユーザーにJAX-RSのサポートを提供する上で最高の立場にあったのです。
その結果、最新版のRestlet 1.1版でJAX-RS 1.0（JSR 311定義によるAPI）完全実装のリリースを発表できることをうれしく思います。Stephan Koops氏の努力の賜物ですが、背景には同氏の修士論文がありました。氏はさらにRestletコミュニティと協力し、実装の開発を続けています。
Koops氏の次の目標はJCP奨学金プログラム経由でTCKにアクセスすること、また、Restletの認定を受けたものにJAX-RSの拡張を与えることです。しかし、私たちは実装の現状にすでにかなり満足しており、現時点で、全コネクタ（Jetty、Grizzly、Simpleなど）やRestletサービス（URIのファイル拡張子からHTTPの適切なコンテントネゴシエーション・ヘッダーへの変換など）の可用性といった、Restlet APIの機能多数を活用できます。
次に、JAX-RSを始める時期としてはいつがよく、ネイティブのRestlet APIを始める頃合いとしてはいつを勧めるか、Louvel氏に聞いた。
この件の決定に際しては、考えるべきことがいくつかあります。Restlet APIはまた、静的ファイルのディレクトリの役割を果たすクラスを提供し、自動的なコンテントネゴシエーションとリモートアップデートもサポートされています。また、リバースプロキシのセットアップに必要なものすべてを提供し、サンドボックス化されたWebブラウザアプリケーションから外部のREST APIへのアクセスを提供します。
- まず、手元には根本的に異なる設計が２つあります。コアRestlet APIでは、Servlet API開発者が馴染み深いと思うような、伝統的なクラス指向の設計に従いました。基本的に、RESTとHTTPの重要概念にはすべて、対応するJavaクラスがAPIに存在するため、理論やプロトコルからRestletの機能に至るまでのマッピングを、頭の中できわめて直観的に行うことができます。
これにより、コンパクトで、再利用可能、拡大可能なフレームワークができあがります。たとえばRestletアプリケーションを、ServletコンテナやOSGiカーネル、SpringおよびGuice IoCのコンテナ、スタンドアロンのJVM、Groovy、Scala、JAIN/SLEEなど、多種多様な環境にデプロイできます。Restlet APIのGWT 1.5（Google Web Toolkit）へのポートさえ行ったので、WebブラウザはあらゆるRESTfulのバックエンドとうまく相互作用できることになり、これはデフォルトのGWT-RPCソリューションを使用した場合とは対照的です。次期バージョンの1.2では、Restlet APIのGoogle Androidへのポートも計画しています！
他方JAX-RSは、どちらかといえば新しいアノテーション指向型の設計に従ってきました。考え方としては、ドメインオブジェクト（POJOs）から始めて、ドメインオブジェクトをアノテートしてREST APIをどのように公開すべきか記述します。理論上は、同じPOJOsにJAXB向けのアノテーションも付けて、XMLやJSONにいかにして直列化するかを記述できます。
しかし、現実のRESTアプリケーションでは、既存のドメインオブジェクトをアノテートするには不十分であるとすぐに気づくでしょう。Web アプリケーションを考え、設計する上で、RESTは根本的に新しい方法を暗示します。私たちがリソース指向パラダイムと呼ぶものです。オブジェクト指向パラダイムに若干似ていますが、保護カプセル化に代わって状態のオープンな表現になり、識別はURIベースになり、インターフェースは（HTTPメソッドに基づいて）統一されます。最も重要なことは、RESTレイヤとサポートするドメインオブジェクト間では粒度が異なり、リソースクラスの新しいセットに定義が必要になる点です。こうしたリソースクラスをアノテートするよりも、ベースとなるRestletのResourceクラスから継承させた方が、簡単かつ強力になると思います。
# さて、JAX-RSはJCPの承認を受けた標準ですから、新プロジェクトの必要条件になることもあるでしょうし、今度のJEE 6標準ではその一部となるので、特にその傾向が強まるでしょう。JAX-RS APIには、ひとつのJAX-RS実装から別の実装へとコードをポートする能力がありますから、そのおかげでベンダーロックインから保護されている感覚になり、企業の中にはJAX-RS APIの方がとにかく快適と感じるところもあります。
- さて、JAX-RSはJCPの承認を受けた標準ですから、新プロジェクトの必要条件になることもあるでしょうし、今度のJEE 6標準ではその一部となるので、特にその傾向が強まるでしょう。JAX-RS APIには、ひとつのJAX-RS実装から別の実装へとコードをポートする能力がありますから、そのおかげでベンダーロックインから保護されている感覚になり、企業の中にはJAX-RS APIの方がとにかく快適と感じるところもあります。
しかし、JEEが初めて定義された所有ソフトウェアの時代と比べて、オープンソース時代における重要性はずっと低くなりました。SpringやHibernate、GroovyがJavaの世界を一変させている様子を考えてください。それに実際には、標準では利用できない機能を各ベンダーは使わせようとしてきます。たとえばクライアント側のサポートといったJAX-RS 1.0には入っていないような機能であり、そうやってある程度のベンダーロックインを再導入しているのです。- 最後になりますが、Restlet APIの機能の範囲はJAX-RSをはるかに上回ります。私たちはクライアント側、サーバー側両方のアプリケーションをサポートし、HTTPセマンティクスへのクリーンなマッピングを使って複数のプロトコル用コネクタ（HTTP、SMTP、POP3、FILE、JDBCなど）をサポートしていますが、そのすべてに使用しているのは統一された単一のAPIです。また、Servlet APIに対する完全な代替物も提供しており、それにはより動的で柔軟なURIマッピング、コネクタ向けのプログラマチックなサポート、認証ホストとバーチャルホストがついています。
結局のところ、プロジェクトでJCP標準のサポートが必要な場合や、プログラミングのスタイルとしてアノテーションの方が好みなら、私たちが提供するJAX-RSを使うようお勧めします。他のケースでは、コアRestlet APIをあくまでも使い続けるように勧めるでしょう。そうすれば、より包括的で直感的なREST/HTTPのサポートが手に入り、より多数のデプロイメントオプションを残しておけます。
最後に、Restletコミュニティについて尋ねた。
Restletコードベースに取り組んでいるコミッターは8人います。コアコミッター２人については、このプロジェクトを推進しているNoelios Technologies社が資金を提供しています。両人はRestletのコア（APIとエンジン）、多数の機能拡張、ビルドプロセス、外部からの貢献の統合を担当しています。最初のリリース以来、当プロジェクトには約160人の貢献者がいます！
JAX-RSやGWT、XDB（Oracle）のような特定の機能拡張を担当する、機能拡張コミッターも6人います。こうしたコミッターは、Solertiumやマンチェスター大学など、他のパートナー組織から資金提供を受けている個人、もしくは開発者のどちらかです。
何よりも重要なことですが、Restletはユーザーとコントリビューターの活気に溢れたコミュニティであり、お互いをサポートしながら、プロジェクトの必要性に最も適した方向へ、団結してRestlet プロジェクトを進めているのです。