いまさら聞けないRESTの基礎知識、JAX-RSを使ったREST APIの作り方と使い方:3つのフレームワークで学ぶエンタープライズJava開発入門(3)(1/3 ページ)
新規のエンタープライズJava開発において現在有力視される3つのフレームの違いについて解説する連載。前回から複数回に分けて、MVCのViewとControllerにフォーカスして各要素を紹介しています。今回はJava EEのJAX-RSについて。JAX-RSの基本的な設計方針であるRESTについて解説し、Struts 1、JSFとの違いやJAX-RSの使いどころを紹介します。
新規のエンタープライズJava開発において現在有力視される3つのフレームワーク、Java EE、Spring Framework、Play Framework。本連載「3つのフレームワークで学ぶエンタープライズJava開発入門」では、3つの違いについて、アーキテクチャ、UI開発/画面の作り方、画面遷移、セッション管理、トランザクション、DBアクセス、開発生産性(ツール/デプロイ/CI/テスト)、外部システムとの連携などの観点から見ていきます。
連載第1回の「Strutsを使い続けることの問題点&現在有力なJava EE、Spring、Play Frameworkの基礎知識とアーキテクチャ」では、本連載で取り上げる3つのフレームワークの概要について解説し、全体的なアーキテクチャを俯瞰しました。
前回の「Strutsと比較して理解するJSFとCDI、アクションベースとコンポーネントベースの違い」から複数回に分けて、Java EE、Spring Framework、Play Framework各フレームワークのControllerやViewについての解説を行っています。前回はJava EEのWebアプリケーション仕様であるJSFを紹介しました。今回は同じくJava EEのWebサービス仕様であるJAX-RSを取り上げます。
JAX-RSは、RESTに準拠したWebサービスを作るためのJava EEの仕様です。本記事ではまず、JAX-RSの基本的な設計方針であるRESTについて解説し、Struts 1やJSFとの違いを明らかにします。その後、サンプルコードを通して基本的な機能を紹介し、JAX-RSの使いどころを紹介します。
RESTとは
REST(Representational State Transfer)とは、端的にいえば、HTTPの仕組みや考え方を最大限に生かしてWebサービスを構築する考え方を指します。特定のアーキテクチャやルールはありません。幾つかの原則や考え方があるだけです。
RESTの4つの原則
RESTによる設計原則は以下の4つに集約できます。
- 【原則1】アドレス可能な「リソース」
RESTでは、情報やデータを全て「リソース」という考え方で表現します。また、リソースはURIによって一意に識別します。
- 【原則2】統一インタフェース
リソースに対して操作をするためのメソッドはHTTPで定義されているGET、POST、PUT、DELETE、HEAD、OPTIONS、TRACEのみを使用します。よく使うのは、GET(取得)、POST(登録)、PUT(更新)、DELETE(削除)の4種類です。
- 【原則3】表現指向とハイパーメディア
リソースをさまざまな形式で表現できるようにします。例えば、HTMLやテキスト、XML、JSON、バイナリなどです。また、関連するデータはハイパーメディア(リンク)としてデータに含めることができます。
- 【原則4】ステートレスな通信
RESTでは基本的に、状態はクライアント側で保持し、サーバとのやりとりで必要な情報は全てリクエストに載せるようにします。これはすなわち、サーバ側ではクライアントの状態を保持するためにセッションスコープを用いないことを意味します。
【利点1】シンプルなAPIを作れる
RESTの利点の1つは、【原則1】と【原則2】により、シンプルなWeb API(以下、API)を作れることです。これは、URIとHTTPメソッドによって処理が決定されるためです。
例えば、従業員番号が「1」の従業員の情報を取得するためのAPIは次のようになります。
GET /employees/1 HTTP/1.1
また、従業員番号が1の従業員の情報を更新するためのAPIは次のようになります。
PUT /employees/1 HTTP/1.1 Content-Type: application/x-www-form-urlencoded name=hoge&age=35
Webサービスの仕様にはRESTの他にもSOAPがあります。SOAPでは開発者が任意の名称のメソッドを定義できますが、WSDLのようなサービスを定義するためのドキュメントが必要になり、大掛かりな仕組みが必要になってしまいます。
一方、RESTでは、URIとあらかじめ決められた数種類のHTTPメソッドのみでAPIを構成するため、WSDLを必要とせずシンプルなAPIが作成できます。
【利点2】XMLやJSON、バイナリなど多様なデータの表現に対応できる
2つ目の利点は、【原則3】により多様なデータの表現に対応できることです。
SOAPではデータの形式はXMLに限定されますが、RESTでは、XMLやJSON、バイナリといったさまざまなデータ表現に対応できます。そのため、ブラウザ以外からのアクセスにも適用が容易です。例えば、JavaScriptのAjaxからのアクセスや、スマートフォンのネイティブアプリからの通信への適用も容易です。
【利点3】スケールアウトが容易
最後は、【原則4】によるステートレス性に関する利点です。ステートレスな通信によりサーバ側で状態を保持しないことから、サーバ側でクライアントごとの状態を保持する必要がなくなります。そのため、サーバ増設による負荷分散が単純でスケールアウトが容易になります。
ただし、ステーレス性については、作成するアプリケーションの内容やフレームワークの機能に応じて、トレードオフが発生することがあります。
プログラムから使用することを前提とした、APIのようなシステムの場合は1度の通信で処理を完結させるために、ステートレスな通信とするべきです。ですが、ブラウザで使用することを前提とした画面ありきのECサイトや業務システムでは、画面の情報をクライアントで持ち回るよりもセッションスコープを用いた方が効率よく開発できる場合があります。
また、セッションスコープで保持することが前提となっているフレームワークもありますので、自前でRESTに対応した認証の仕組みを作るよりも既存の仕組みを利用した方が良い場合があります。
RESTの設計ではURIが重要
従来はURIが示すのは対応するプログラムでしたが、RESTではURIが示すのはリソースです。リソースとは単純に言えばそのシステムで扱う主要なデータを指します。そのデータをどう操作するのかをHTTPメソッドによって決めます。例えば、GETでデータを取得する、PUTでデータを更新するといった具合です。つまり、RESTではリソースが主役といえます。
システムのデータ構造をリソースとして適切にURIで表現できると、システムの利用者に対して、推測しやすく直感的なAPIを提供できます。
RESTに対応したフレームワーク
RESTはJAX-RSだけではなく、今後紹介するSpring FrameworkやPlay Frameworkの他、Ruby on Railsといった他言語のフレームワークにも影響を与えています。GoogleやAWSが提供するサービスなどもREST APIの形式で公開しています。RESTはどこにでも登場してきますので覚えておいて損はありません。
ただし、RESTはシンプルですが奥が深いため、Struts 1から移行するとなるとアプリケーション設計に対する考え方をシフトする必要があります。
JAX-RSとは
JAX-RS(Java API for RESTful Web Services)は、前述したRESTの原則に沿ったWebサービスをJavaで構築するための仕様です。JAX-RSのバージョン1.0が策定されたのは2008年で、Java EE 6から採用された比較的新しい仕様です。Java EE 7ではJAX-RSのバージョンは2.0です。
JAX-RSは学習コストが少なく、シンプルなWebサービスを作るのに適しています。拡張機能を導入することでMVCフレームワークとしても使うこともできます。応用範囲が広くどこでも使えるフレームワークといえます。
Struts 1と違って、設定ファイルや継承を用いず、多くの設定をアノテーションで行うのが特徴です。
JAX-RSによるプログラムは、基本的にRESTのリソースと対応するリソースクラスを作成し、リソースクラスのメソッドにHTTPメソッドや表現形式をアノテーションで設定していきます。リソースクラスは、JAX-RSの主要な要素であり、Struts 1のアクションやJSFのコントローラーに相当します。
JSFとの違いは連載第1回で解説してます。概要についての図を再掲しておきます。
JSF、Struts 1とJAX-RSの違い
JSFやStruts 1もHTTPを使用しています。ですが、これらのフレームワークではHTTPを重視せず、クライアントとサーバ間でデータを送るための経路くらいに考えています。
例えば、JSFではHTTPのやりとりは隠蔽されていて開発者が意識することはほとんどありません。また、Struts 1では、Actionクラスと対応付けるのはURIのみです。URIに対して、GET、POSTどちらの呼び出しでも同じActionクラスのメソッドが実行されるので、HTTPメソッドによる処理の違いをさほど意識する必要がありません。
RESTによるアプリケーションを作成する場合は、今までは深く考慮する必要がなかった、URIの設計やHTTPメソッドの使い分けなど、HTTP仕様に基づいた設計について考慮する必要があります。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- Struts後時代のJava EE/Javaモダン開発はどうあるべきか〜JJUG CCC 2014 Springまとめリポート(前編)
Java EEにおいてJava 8はどこまで利用できるのか、Java開発でGit、CI、継続的デリバリは、どこまで有効なのか、Struts後時代のJava EE開発における有効なフレームワークなどをお伝えする。 - 日本の開発者コミュニティが次世代Java仕様策定に貢献、Lambdaを手に入れたJavaテクノロジのその先へ
2015年4月8日、Javaテクノロジに関する開発者イベント「Java Day Tokyo 2015」が開催された。基調講演で紹介されたJavaテクノロジに関する話題を解説していきたい。 - Java 8時代の開発者のためのデバッグ/トラブル解決の基本・応用テクニック〜JJUG CCC 2014 Springまとめリポート(後編)
Java開発における3大トラブルと対策、IDEのデバッガー活用の必要性、Java 8より導入された新しいメモリ領域を使いこなすためのテクニック、独自のトランザクショナルメモリ機構を実装した有効性などをお伝えする。