JSR 311: RESTfulなWebサービスのためのJavaのAPI仕様が確定

作者 Stefan Tilkov , 翻訳者 佐野 徹郎 投稿日 2008年10月13日

セクション

デベロップメント,

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ

トピック

SOA ,

REST ,

Java

タグ

URI ,

Web services ,

HTTP

2007年2月、SunはJSR 311 : The Java API for RESTful Web servicesを発表した (リンク)。先日、その仕様のドラフト1.0が、JCPのEC(Executive Committee)による承認投票をパスした(リンク)。それは実質的に仕様が確定したことを意味する。

JAX-RSは(リンク)、JavaでHTTPに基づくRESTfulなWebサービス(参考記事・英語)を実装するための、アノテーションベースのAPIだ。基本的にクラスとメソッドは、それらを実行時にリソースとして公開するための情報によって注釈される。そのアプローチは、サーブレットのプログラミングモデルによって公開されるものとは大きく異なる。HTTPプロトコルとJavaクラスを仲介するJAX-RSを実装するランタイムは、URI、要求されたコンテンツタイプと受け取ったコンテンツタイプ、そしてHTTPメソッドを考慮する。Sunのリファレンス実装であるJersey(リンク)に加えて、ポピュラーなRestlet(リンク)フレームワークの一部、JBossのRESTeasyプロジェクト(リンク)、WebサービススタックであるApache CXF(リンク)の一部など、(完成度は様々だが)その他の実装も利用できる。

InfoQではスペックリードであるSunのMarc Hadley(リンク)とPaul Sandoz(リンク)に、JAX-RSとそのプロセスに対する見識について話を聞いた。

その結果にどれくらい満足しているかという質問に、MarcはAPIの出来にとても満足していると答えた。彼はまた、専門家グループがAPIを策定している間に、とても多くの実装が作成され、それらが実際にいくつかの問題の解決に役立ったのは、とても幸運なことだと考えている。Paulは自発的にそれらのAPIの実装を試し、フィードバックを提供してくれる開発者がいたことを付け加えた。

最も挑戦的な点についてたずねると、Marcは最初にAPIのスタイルとスコープについての合意を得るのが難しかったと述べた。

私たちはJSRを活性化するために、かなり包括的な提案から始めましたが、今にして思えば、もっと骨組みの構築から始めたほうが良かったのではないかと思います。この数ヶ月、私たちはJSRについて多くの興味深いものを見てきました。そして主な課題は、すべての新しいインプットに対応しながら、スケジュールを守ることでした。

PaulはJSRの「J」について、大胆な疑問を述べた。

もしかするとこれは少し異端かもしれませんが、私は時々、現在のJava言語の構文自体が、ちょっと難しいと思うことがあります。それでも、Javaのアノテーション、ジェネリクスおよびビルダーパターンによって、どうにか簡潔なレベルにすることができたと思います。さらに、Javaのバイトコード互換のアノテーションをサポートするScalaやGroovyなら、容易にJAX-RSアプリケーションを書くことができます。

JSRを始めたとき、RESTコミュニティには、RESTの基本原則に従うことについて、いくつかの疑念があった(参考記事・英語)。Marcはこの目標は達成されたと考えている。

私はこのAPIがリソース中心の考えを促し、それらのリソースの識別とそれらをサポートするメソッドについて、開発者に考えさせると思います。宣言的なコンテントネゴシエーションのサポートはうまく働き、デフォルトのリソースライフサイクルはステートレスなアプローチを促します。もし私が弱点を特定しなければならなかったとしたら、それは状態の原動力であるハイパーメディアに対する限定されたサポートだったでしょう。私たちはリクエストするURIやリソースのURIから情報を抽出するための良いサポートを提供しますが、それでもハイパーメディアの適切な表現の利用は、いまだに開発者に委ねられています。

Paulも同意する。

確かにこれは難しい領域です。JAX-RSはURIを構築する一連の方法を提供しますが、それはJAXBなどのモデリングAPIのような、URIバインディングのための機能ではありません。これに関しては、例えばHenry StoryのRDFシリアライゼーション(リンク)などのように、検討できることがいくつかあると思います。

JSR 311での作業がWebとWebサービスに対する彼の見解を変えたかという質問に、Marcは「より複雑なことに頼らないHTTPによるとても多くのこと」ができることについて、彼の見解を確認したと述べた。PaulはRESTのうれしい驚きの例として、RESTの発明者であるRoy Fieldingによる、通知のためのスパースビット配列の利用を挙げた(リンク)。

我々はMarcに、JSR 311がサーブレットの次の仕様リビジョンに、どのような影響を与えると思うかについても話を聞いた。

その2つをうまく一緒に動かすために、JAX-RSアプリケーションはサーブレットコンテナの中で実行されます。JAX-RSは新しいサーブレットのプラグイン可能なフレームワークの潜在的な顧客で、私たちはこれに関するインプットを提供しました。ひとつのトリッキーな側面は、JAX-RSがリソースマッピングのために、サーブレットよりも柔軟なURIを提供できることです。これはJAX-RSによる宣言的なサーブレットセキュリティの利用にチャレンジさせます。そして私たちはこれに関しても作業を行っています。

最後にMarcは、Jerseyは「単なる」リファレンス実装ではなく、確実に製品で利用可能なものであり、すでに実際の開発で利用されていると述べた。彼はまた、JerseyはGlassfishのJSR 311の実装になるので、製品としての品質が必要だと述べた。Paulはもう一つの理由を強調した。

仕様や実装のEarly Access版を定期的にリリースする利点の一つは、APIと実装の両方を早期に繰り返しテストしてもらえることです(笑)。

仕様は(リンク)オンラインでチェックアウトできる。リファレンス実装であるJerseyは(リンク)java.netにあり、Java 5以上で動作する。

原文はこちらです：http://www.infoq.com/news/2008/09/jsr311-approved

• 次へ >