第45章 RESTful Web サービスの概要
概要
REST (Representational State Transfer) は、4 つの基本的な HTTP 動詞のみを使用して、HTTP を介したデータの送信を中心としたソフトウェアアーキテクチャースタイルです。また、SOAP エンベロープなどの追加のラッパーや状態データの使用を避けます。
概要
Representational State Transfer (REST) は、Roy Fielding という研究者による博士論文で最初に説明されたアーキテクチャースタイルです。RESTful システムでは、サーバーは URI を使用してリソースを公開し、クライアントは 4 つの HTTP 動詞を使用してこれらのリソースにアクセスします。クライアントがリソースの表現を受け取ると、クライアントはある状態に配置されます。通常はリンクをたどって新しいリソースにアクセスすると、状態が変化または遷移します。REST は、リソースが普及している標準文法を使用して表現できることを前提として機能させます。
World Wide Web は、REST の原則をもとに設計された、最も普及しているシステムの例です。Web ブラウザーは、Web サーバーでホストされているリソースにアクセスするクライアントとして機能します。リソースは、すべての Web ブラウザーが使用できる HTML または XML 文法を使用して表されます。ブラウザーは、新しいリソースへのリンクを簡単にたどることもできます。
RESTful システムの利点は、拡張性と柔軟性が高いことです。リソースは 4 つの HTTP 動詞を使用してアクセスおよび操作されるため、リソースは URI で公開され、標準の文法で表現されるので、サーバーに変更が加えられてもクライアントへの影響はありません。また、RESTful システムは、キャッシングやプロキシーなどの HTTP のスケーラビリティー機能を最大限に活用できます。
基本的な REST の原則
RESTful アーキテクチャーは、次の基本原則に準拠しています。
- アプリケーションの状態と機能は複数のリソースに分けられます。
- リソースは、ハイパーメディアリンクとして使用できる標準 URI でアドレス指定できます。
すべてのリソースは、4 つの HTTP 動詞のみを使用します。
-
DELETE -
GET -
POST -
PUT
-
- すべてのリソースは、HTTP でサポートされている MIME タイプを使用して情報を提供します。
- プロトコルはステートレスです。
- 応答はキャッシュ可能です。
- プロトコルは階層化されています。
Resources
リソース は REST の中心です。リソースは、URI を使用してアドレス指定できる情報のソースです。Web 登場した頃は、リソースは主に静的なドキュメントでした。最近の Web では、リソースは任意の情報源はさまざまです。たとえば、URI を使用してアクセスできる場合には、Web サービスをリソースにすることができます。
RESTful エンドポイントは、アドレス指定するリソースの 表現 を交換します。表現は、リソースが提供するデータを含むドキュメントです。たとえば、顧客レコードにアクセスできるようにする Web サービスのメソッドはリソースで、サービスとコンシューマーの間で交換される顧客レコードのコピーはリソースの表現です。
REST のベストプラクティス
RESTful Web サービスを設計するときは、次の点に注意してください。
公開するリソースごとに個別の URI を指定します。
たとえば、運転記録を処理するシステムを構築している場合には、各記録には一意の URI が必要です。システムが駐車違反やスピード違反の罰金に関する情報も提供する場合は、各タイプのリソースにも固有のベースが必要です。たとえば、スピード違反の罰金は /speedingfines/driverID を介してアクセスでき、駐車違反は /parkingfines/driverID を介してアクセスできます。
URI で名詞を使用します。
名刺を使用すると、リソースがモノで、アクションではないことが強調されます。/ordering などの URI はアクションを、/orders はモノを意味します。
-
GETにマップするメソッドはデータを変更しないでください。 応答にはリンクを使用してください。
応答に他のリソースへのリンクを含めると、クライアントが一連のデータを簡単にたどることができます。たとえば、サービスがリソースのコレクションを返す場合には、クライアントは提供されたリンクを使用して各リソースにアクセスするのが簡単になります。リンクが含まれていない場合には、クライアントは特定のノードへのチェーンをたどるためにロジックが追加で必要です。
サービスをステートレスにします。
クライアントまたはサービスで状態情報を維持させると、この 2 つが強制的に疎結合されます。疎結合であることが原因で、アップグレードと移行がより困難になります。また、状態を維持すると、通信エラーから回復するのがより困難になる可能性もあります。
RESTful Web サービスの設計
RESTful Web サービスの実装に使用するフレームワークに関係なく、従う必要のあるステップがいくつかあります。
サービスが公開するリソースを定義します。
一般的に、サービスは、ツリー編成されたリソースを 1 つ以上公開します。たとえば、運転記録サービスは次の 3 つのリソースに編成できます。
- /license/driverID
- /license/driverID/speedingfines
- /license/driverID/parkingfines
各リソースで実行できるようにするアクションを定義します。
たとえば、ダイバーの住所を更新したり、運転免許証から駐車違反切符を削除したりできるようにする場合などです。
- アクションを適切な HTTP 動詞にマップします。
サービスを定義したら、Apache CXF を使用してサービスを実装できます。
Apache CXF を使用した REST の実装
Apache CXF は、RESTFul Web サービス (JAX-RS) 用の Java API の実装を提供します。JAX-RS は、アノテーションを使用して POJO をリソースにマップするための標準化された方法を提供します。
抽象サービス定義から JAX-RS を使用して実装された RESTful Web サービスに移行する場合は、次のことを行う必要があります。
サービスのリソースツリーの最上位を表すリソースのルートリソースクラスを作成します。
「ルートリソースクラス」 を参照してください。
サービスの他のリソースをサブリソースにマップします。
「サブリソースの操作」 を参照してください。
各リソースで使用される各 HTTP 動詞を実装するメソッドを作成します。
「リソースメソッドの操作」 を参照してください。
Apache CXF は、Java インターフェイスを RESTful Web サービスにマップする、以前の HTTP バインディングを引き続きサポートします。HTTP バインディングは基本的な機能を提供し、いくつかの制限があります。開発者は、JAX-RS を使用するようにアプリケーションを更新することを推奨します。
データバインディング
デフォルトでは、Apache CXF は Java Architecture for XML Binding (JAXB) オブジェクトを使用して、リソースとその表現を Java オブジェクトにマップします。Java オブジェクトと XML 要素の間で、正確かつ明確に定義されたマッピングを提供します。
Apache CXF JAX-RS 実装は、JavaScript Object Notation (JSON) を使用したデータ交換もサポートしています。JSON は、Ajax 開発者が使用する一般的なデータ形式です。JSON と JAXB の間のデータのマーシャリングは、Apache CXF ランタイムによって処理されます。
