JAX-RSは、1年以上にわたって標準であり その間、 RESTeasy, CXF と Jersey（これはサンによるリファレンス実装である）のようないくつもの実装が登場した。ついにJAX-RSが批准されたとき、 Stefan Tilkov氏は、JAX-RSについての見解をスペックの設計主任であるMarc Hadley氏とPaul Sandoz氏にインタビュした。
JSRが導入された時、RESTの主要な原則に合うのかについて、RESTのコミュニティでは、疑う向きがあった。
Marc氏は、この目標は達成した、と考えている: 私は、APIのおかげで、リソース中心の見方を強め、開発者は自分たちがサポートするリソースの識別子やメソッドについて考えるようになる、と思います。コンテント・ネゴーシエイションに対する宣言型のサポートは、うまく機能しており、既定のリソースのライフサイクルにより、ステート・レスな手法を採ることになります。弱点を言うなら、ステートのエンジンとして、ハイパーメディアへのサポートが限られていることです。リクエストURIから情報を抽出して、リソースへのURIを作ることは、うまくサポートしています。ハイパーメディアを使う、適切な表現方法は、まだ多分に開発者に依存します。
Paul氏も同意している: そうです、これはおそらく最も難しい領域ですね。JAX-RSは、URIを作り上げる方法をたくさん提供していますが、そのようなURIをJAXBのようなモデリングAPIと簡単に結合することができません。私は、この点で、我々がやれることがいくつかあると思います。例えば、Henry Story氏のRDFシリアライズです。
Javaコミュニティでは、確かに過去12カ月間に、JAX-RSを基にしたプロジェクトの数が増えてきた。多くの人がこれは、正しい方向に向かったステップだと考えている。しかし、必ずしも皆が同意しているわけでなない。最近、 restfulieプロジェクトリーダーであるGuilherme Silveira氏が、彼のプロジェクトと RESTeasyとを比較、対照した面白い記事を載せている。後に、JAX-RSについてもっと正確に述べるべきだったとか、特定の実装についてのものではないなど、いくつかの指摘はあったが。 resfulieのサイト によると、その目的は、以下のように要約される:
HTTPを通してのCRUDは、リソースを使い、RESTfulになるために、よいステップであり、更なるステップを進めるには、ハイパーメディア ベースのサービスを利用することである。Restfulie gemを使えば、非常に速くそうすることができる。
Guilherme氏は、記事の中で、RESTeasy は、JAX-RSを非RESTful にし、restfulie は、それに追随しない、と信じていると、RESTeasyについていくつかの課題を指摘している:
- 強結合とパイパーメディア無知: "今日現在、Resteasyでは、すべてのリソース操作を特定のメソッドにマッピングするインターフェースを作る必要があり、望みのターゲットURIを明記するには、@VerbName と@Path アノテーションを使います"
- RESTEasyは、Roy T. Fieldingの言うRESTではない: Guilherme氏によれば、RESTfulなシステムでは、早期バインディングは、強結合なシステムを助長するので使うべきでない。 "@VerbName + @Pathアノテーションを使ったJavaインターフェースは、早期バインディングを意味し、どのURIにどのメソッドを使うかを記述しょうとする労力を意味します。より密結合で、サーバー・システムが進化する余地がより小さくなります"
- サーバー側: "RESTEasyは、パイパーメディア コンテント用の既定のインターフェースを提供しません。しかしJAX-RSは、JAXBのプレーンのxmlを既定でサポートします。疎結合のシステムを作るためにパイパーメディア システムをどのように利用するかを理解するのは、（よい）プログラマ次第です。"
- 言語: "Restfulie手法に関するもう一つの重要な点は、Java-独立だ、ということです。毎月、他の言語で開発されたかなりの数の統合ソフトウェアを見ます：Restfulieは、すでにJavaとRubyの開発者を助けています。"
その著作がrestfulieに影響のあるJim Webber氏は、 この記事について意見を述べた:
全体的に、テーマである彼の分析は、正確だと思います。RESTEasyは、そのままでは、パイパーメディアをサポートしません。決してRESTfulではない、ということです。
しかし彼が更に言うには:
しかし私は、これがRESTEasyの欠点とは思いません。実際、RESTEasyが住むBizzaro-worldでは、それは模範的な市民だと思います。分別のあるJavaベンダーが、企業とJCPの間に挟まれて、適当なJSRに従う（そして影響を与える）以外に選択できるものがありますか？ですから、ここで間違っているのは、RESTEasy (やJerseyや CXF)ではなく、委員会主導のプロセスです。ここには、様々な目的とRESTについての理解のレベルが様々な人たちが、JAX-RS（よくない名前です。せいぜいJAX-RSは、webサーバの上にあるプログラムの層を提供しているだけですから。）と呼ばれる最小公倍数を導き出すために集まるのです。
Bill de hora 氏は、この記事に同意しないコメントを書いている:
私はこの記事とGuilherme氏のを読みましたし、彼のフレームワークを見ましたが、そんなに不満はありません。JAXBが悪いと知り、いつもサーバでもクライアントでもJerseyを使っています。JAXBを使っていません。使わなくてはならないことはありました。それは実装の内部で（とるに足らないシステム用の容易な変換ツールとして）。他のあらゆるwebフレームワークを盲撃ちできないんでしょうか？単に、HttpClient やjava.net.*で楽しむことを考えてください。今日、低レベルのものは、リンクから起動されるAbderaとJerseyクライアントの上で、いくつかの楽しいコードを書きました。皆ちゃんと動きました。もし問題が、オブジェクト指向パラダイムは、単にハイパーテキスト駆動のシステムに弱い、ということであれば、私は、それに同意します。...
そしてStefan Tilkov氏が付け加えます:
Restfulieは、幾つかの点で、非常に具体的な決断をしており、RESTfulなソリューションをもたらしています。しかし（どんな種類の） RESTfulシステムでも作れるような一般的なフレームワークでは、ありません。私は、違った問題のドメインで競争したり、問題に対処したりできるとは思いません。
John Nackman氏がGuilherme氏に元々の記事ついて述べたのは ...
おもしろい、でもこれは、実際、客観的な分析ではないですね。少なくとも、RESTEasyが標準に則っているという事実を無視してます。あるいは、標準が開発者にとって重要でないと考えるのですか？私は、もっと徹底したそして客観的な議論が、全体としてコミュニティに有益だと思います。
元の記事が正確かどうかについて、多くの議論を引き起こしたのを別にすれば、JAX-RSは多くのことが、不明確なままだ、ということなのか？開発者達は、現在の実装から余りに多くのことを推測しすぎているのか？RESTeasyのチーフであるBill Burke氏の見解を最後に載せる:
RESTEasy とJAX-RSは、RESTful なwebサービスやクライアントソフトを書くのを助けるためにあるのです。ツールです。ハイパーメディアは、非常にアプリケーションに依存しがちです。なので、私見では、ハイパーメディアがアプリケーションの設計に割り込む前に、フレームワークができることは、たくさんあります。RESTは、分散したインターフェースを書くのに役立つアーキテクチャ上のガイドラインです。RESTは、コードを書いたり、詳細設計に役立つガイドラインではありません。私は、JAX-RSに、はまってますが、それはRESTfulなサービスを書くのに最も疎結合的に書く助けになると考えたからです。JAX-RSは、開発者にRESTfulなサービスの*実装*方法に多くの柔軟性を与えます。ここでは、実装がキー・ワードなのです。
注：Guilherme氏との別のインタビュを後日掲載予定。