Javaがこれまで長年にわたってソフトウェア開発の世界に肯定的な影響を与えてきたこと、すなわちJavaとJVMが多くの開発者とアプリケーションに対する主要な、汎用的ソリューションであり続けることを誰も否定することはできない。 CORBA, Java EE, SOA, REST あるいは Web サービスがあるが、Javaはこれらすべてをサポートすることができる。JavaとRESTが広く普及していることを考えれば、この2つを合体する、標準をベースにしたアプローチが現れるのは、単に時間の問題だった。そしてそれが JAX-RSであり、EE6で導入された。多くのJAX-RS実装があり、その中には、 Jersey（参照実装）や RESTeasyがあり、広く使われている。
長年にわたり、JAX-RSについて批判があるが、特にそれがRESTfulな設計を奨励しているのかどうかについてである。これらの問題の幾つかは、JAX-RS 2.0技術委員会でによって取り上げられたが、最近のJavaOne 2012でも、標準について未だ、質問があった。今月始めに、 JavaそしてJAX-RSでさえ RESTfulアプリケーションを作成するのに適切なのかどうか、という質問を再度投じる記事により Zapthinkが議論に加わわった。
Java Community Process (JCP)の継続的な努力によって、広範囲の新しい問題や状況に対処するために、Javaエコシステムの能力を増強してきました。Javaに関する継続的な開発が将来、長年にわたってあなたのニーズに応え続けるかもしれない。しかし、またそうでないかもしれない。重厚なJava EEのmodel-view-controller (MVC)アーキテクチャ、あるいは単純にもっと広く、Javaのオブジェクト指向コンテキストは、代替のアーキテクチャ的なアプローチをサポートしないかもしれない。
もちろん、Javaに無関係で、盛んなJVMコミュニティもある、例えば、 JRuby, Clojure, Scala、JavaScriptである。中からJavaEEの多くの機能、例えば、トランザクション、セキュリティなどを使うためにJava EEに触れる必要はない。そしてこれらの言語のあるものは、RESTfulサービスを構築するのに独自のアプローチを持っている。しかし、Zapthinkは、Javaは、特に JAX-RSと上手くいかない、と信じている。
不幸にも、JAX-RSは合わないものを無理に合わせようとする古典的な例です。それはJavaにある程度のRESTful 機能を追加しますが、RESTfulなアーキテクチャスタイルとあらゆる段階で格闘しています。代表例は、Hypermedia as the Engine of Application State (HATEOAS) の制約です。 JAX-RS 1.1は、ハイパーメディアを全くサポートしていませんでした。その本質的な意味は、我々は、コアJavaの機能を使うことによって、HATEOAの特徴をシミュレートしなければならなかった、ということです。JAX-RSを完全にRESTfulにするには、RESTのアーキテクチャ制約の全てを満足するアプリケーションを設計しなければならなく、開発段階では、充分なサポートがなかったそれらのフィーチャを埋め合わせすることになります。JAX-RS 1.1はある程度、RESTアーキテクチャの制約を満足するような、充分なサポートを提供していますが、HATEOASはそういきません。
ハイパーメディアのサポートが無いことは、JAX-RS技術委員会が最新版で対処しようとしたが、その記事によると上手く行かなかった。 JAX-RSはJavaアノテーションを多用しているが、ハイパーリンクを表すアノテーションがなく、それらが標準の一部となるべきなのに、アドホックなアプローチになってしまった。記事によると、標準の新バージョンでさえ扱っていない他の領域もある。これらが JAX-RSかあるいは、他の標準に属するべきなのかは議論の要るところではあるが。
可能なときはいつでも、カスタムなメディア・タイプを標準化するのも重要です。使うべきなのはどの標準メディア・タイプとカスタムなメディア・タイプなのかも選ばなければなりません。更にサービス発見可能性の設計原則は、REST HATEOAS 設計制約をベースにしたハイパーメディア制御を適切に持つことを要求しています。発見可能性はプロトコルを自己ドキュメント化する方法を提供します。
最後に JAX-RSに課せられた重要な制約が１つあり、そのためにそれとJava が RESTful サービスに適切でないと、 Zapthinkは考えている。Arun Gupta氏が JAX-RS 2.0の早期ドラフトを話題にした時に説明したように、ハイパーメディア内のリンクには2つのタイプがある。
リソースを一緒に結ぶのは、主要なRESTful原則の１つです。構造的リンクは、リソースの完全な表現を送るのを避けるために使われ、遅延ローディングができます。クライアントは、必要な「部品」を取り出すためにこのタイプのリンクを追うことができます。暫定的リンクは、リソースの状態をアップデートするために使われ、一般的には"rel" アトリビュートによって識別されます。構造的リンクは、通常エンティティ中にあり、暫定的リンクは、リンクヘッダかエンティティ内にあります。
しかし、 JAX-RS 2.0は暫定的リンクしかサポートしない、という事実にもかかわらず、Zapthinkは、 どちらもRESTfulサービスには、厳密には必要でない、と信じている。
もし我々が単にJavaオブジェクトを取り上げ、これをハイパーメディアに変換するのであれば、関係するオブジェクトインスタンスに対する様々なメソッド呼び出しのすべてを表すリンクで終り、過渡に大きく、複雑な表現になってしまいます。その代わりJAX-RS は、クライアントが下層の集合データまで掘り下げられるようにする、暫定的リンクを奨励します。しかし、もし我々がまず、Javaオブジェクトの構造に囚われなかったら、暫定的リンクと構造的リンクで悩むことはなかったでしょう。その代わりに、発見可能性をサポートするように、我々のハイパーメディアアプリケーションを設計したでしょう。言い換えれば、コアのJavaパターンは、ハイパーメディアのアンチパターンになります。
JAX-RS 2.0が RESTfulサービスを構築するのに未だに不完全である、という事実を別にして、著者の結論は、RESTは実装ではなく、アーキテクチャ的なアプローチである、ということを憶えておく必要がある、ということである。
人々は、JAX-RSを使って開発し、RESTを考えている時にしばしば混乱します。 JAX-RSはRESTの設計ではありません。そうではなく、JAX-RSは、良い RESTfulな設計をサポートすべきです。更に、JAX-RS API を使っても、完全な RESTfulサービスを作成できるできるわけではありません。その前に適切な RESTful設計を終わらせておく必要があります。設計は、全てのRESTfulアーキテクチャの制約を満足していることを保証する必要があります。
もちろん、これはRESTや SOAに関して、以前他の人が言ったことである。しかし、 Zapthinkの記事に書かれたように、RESTfulサービスを構築するのに JAX-RS や Javaには何か根本的な問題があるのだろうか？この記事に対する評者の一人が質問している。
冗談抜きで、RESTfulアプローチの要るシステムを構築する時、Javaの代わりにどの言語を推奨しますか？Javaは「薹が立ってきた」のは理解できますが、私はJavaが具体化した強い型づけと他のプログラミングプラクティスの恩恵を強く信じています。あなたはScala（Javaの次の論理的進化）のほうがもっと適切だと考えますか？もしScalaでないのなら、何を薦めますか？
著者が応えている。
私はこの場合、ある言語を他のものよりも良いとは、言えません。それは単に、どんなプログラミング言語でも、REST準拠のアーキテクチャ実装を充分サポートしている限り、適したものになり得ると信じているからです。もちろん、アーキテクチャは、選んだ言語の影響をある程度受けます。しかし、この場合もっと重要なのは、RESTの設計制約に適応するように、アプリケーションを設計することに焦点を合わせることです。
未だ疑問が残る。Javaは RESTful設計に合わないのか？特に他の言語よりも適さないのか？