JAX-RSより前のWebフレームワークと比べると、JAX-RSはアノテーションを利用することでアプリケーションの実装クラスそのものは圧倒的にシンプルなものになる。
このシンプルさの裏側で何が行われているのかは知っておいた方がよいだろう。
ここで例にしたAddクラスがどうやってWebサービスとして機能しているかを以下に示す。
以下に上記の概要をまとめた図を示す。
JAX-RSアノテーションをどのように利用しているかを理解すると、クライアントに与えたいアクセス方法に対してどのようなアノテーションを行うべきかが分かる。
この記事では、JAX-RSについて解説した。
JAX-RSはJavaの普通のクラスにアノテーションを付けることでWebサービス化するためのフレームワークだということを、ごく単純なクラスを利用して示した。
大きなストーリーとしては、冒頭に書いた通り、JAX-RSはREST(RESTについては最後に紹介する参考文献を参照のこと)なアーキテクチャで分散システムを構築するためのフレームワークだ。しかし、必ずしもREST原則に従って利用する必要はない。
例えば単純な既存のユーティリティクラスをWebサービス化することを考えてみよう。その場合は、RESTではなく、RPC(リモート関数)としてサービスを公開する方が適切だ。
実際問題として、クライアントサイドのJavaScriptを駆使したシステムで、しかし10桁を超えるような金額を正確に計算する必要があるとしたら、JavaScriptで頑張るよりも、JavaでBigDecimalを利用した演算サービスを実装してそれを呼び出した方がよい。このような用途に対してRESTなアーキテクチャは意味を持たない。かといってEJBを持ち出すのは今となっては大げさ過ぎる。
JAX-RSによる計算サービスこそが適切な解だ。
以上を強調した上で(つまり、非RESTな利用方法も全く問題ないということ)、以下に参考文献を挙げる*8。
*8 なぜ、非RESTでも問題ないかを強調するかというと、RESTは実に魅力的であり、合理的であり、示唆に富んだアーキテクチャパターンだからだ。そのために免疫なしにRESTを知ると、システムの適合性を無視して隅から隅までRESTなアーキテクチャでシステムを構築しようとして破綻する危険がある。
Copyright© Digital Advantage Corp. All Rights Reserved.