Menu Close

第45章 RESTful Web サービスの概要

概要

Representational State Transfer (REST) は、4 つの基本的な HTTP 動詞のみを使用して、HTTP でのデータ転送を中心とする、ソフトウェアアーキテクチャースタイルです。また、SOAP エンベロープなどの追加のラッパーの使用や、状態データの使用もありません。

概要

Representational State Transfer (REST)は、Roy Fielding という研究者による博士論文で最初に記述されたアーキテクトスタイルです。RESTful システムでは、サーバーは URI を使用してリソースを公開し、クライアントは 4 つの HTTP 動詞を使用してこれらのリソースにアクセスします。クライアントはリソースの表現を受け取ると、ある状態になります。通常、リンクをたどって新しいリソースにアクセスすると、その状態が変化したり、移行したりします。機能するために、REST はリソースが普及した標準文法を使用して表現できることを仮定します。

ワールドワイドウェブは、RESTの原則に基づいて設計されたシステムの最も遍在的な例です。Web ブラウザーは、Web サーバーでホストされるリソースにアクセスするクライアントとして機能します。リソースは、すべての Web ブラウザーが消費できる HTML または XML 文法を使用して表現されます。ブラウザーは、新しいリソースへのリンクを簡単にたどることができます。

RESTful システムの利点は、非常にスケーラブルで柔軟である点です。リソースは 4 つの HTTP 動詞を使用してアクセスおよび操作されるため、リソースは URI を使用して公開されます。リソースは標準文法を使用して表されるため、クライアントはサーバーに対する変更の影響を受けません。また、RESTful システムは、キャッシュやプロキシーなどの HTTP のスケーラビリティー機能を最大限に活用できます。

基本的な REST 原則

RESTful アーキテクチャーは、以下の基本原則に従います。

  • アプリケーションの状態と機能は、リソースに分割されます。
  • リソースは、ハイパーメディアリンクとして使用できる標準 URI を使用してアドレス指定できます。
  • すべてのリソースは 4 つの HTTP 動詞のみを使用します。

    • DELETE
    • GET
    • POST
    • PUT
  • すべてのリソースは、HTTP でサポートされる MIME タイプを使用して情報を提供します。
  • プロトコルはステートレスです。
  • 応答はキャッシュ可能です。
  • プロトコルは階層化されています。

リソース

リソース は REST の中心になります。リソースは、URI を使用してアドレス指定できる情報源です。Web の初期には、リソースは主に静的ドキュメントでした。最新の Web では、リソースはあらゆる情報源になります。たとえば、URI を使用してアクセスできる場合、Web サービスはリソースになります。

RESTful エンドポイントは、アドレスするリソースの 表現 を交換します。表現は、リソースが提供するデータが含まれるドキュメントです。たとえば、顧客記録へのアクセスを提供する Web サービスのメソッドはリソースであり、サービスとコンシューマーの間で交換される顧客記録のコピーは、リソースの表現です。

REST のベストプラクティス

RESTful Web サービスを設計する場合は、以下の点に留意してください。

  • 公開するリソースごとに、異なる URI を提供します。

    たとえば、運転記録を扱うシステムを構築する場合、各レコードには一意の URI が必要です。システムが駐車違反やスピード違反に関する情報も提供する場合は、各タイプのリソースにも固有のベースが必要です。たとえば、/speedingfines/driverID でスピード違反にアクセスでき、駐車違反は /parkingfines/driverID でアクセスすることができます。

  • URI で名詞を使用します。

    名詞を使用すると、リソースが物であり、動作ではないという事実が強調されます。/ordering などの URI は動作を意味しますが、/orders は物を意味します。

  • GET にマップするメソッドはデータを変更しないでください。
  • 応答のリンクを使用します。

    レスポンスに他のリソースへのリンクを配置すると、クライアントがデータのチェーンをたどるのが容易になります。たとえば、サービスがリソースのコレクションを返すと、クライアントは提供されたリンクを使用して個々のリソースにアクセスしやすくなります。リンクが含まれていない場合、クライアントはチェーンを特定のノードに追従するための追加のロジックが必要です。

  • サービスをステートレスにします。

    クライアントまたはサービスに状態情報の維持を要求すると、両者の間の密接な結合が強制されます。密接な結合により、アップグレードおよび移行がより困難になります。状態を維持すると、通信エラーからの復旧がより困難になります。

RESTful Web サービスの設計

RESTful Web サービスの実装に使用するフレームワークに関係なく、以下の手順に従う必要があります。

  1. サービスが公開するリソースを定義します。

    一般的に、サービスはツリーとして編成された 1 つ以上のリソースを公開します。たとえば、運転記録サービスを次の 3 つのリソースに編成できます。

    • /license/driverID
    • /license/driverID/speedingfines
    • /license/driverID/parkingfines
  2. 各リソースで実行できるアクションを定義します。

    たとえば、運転手の住所を更新したり、運転手の記録から駐車違反切符を削除したりできます。

  3. アクションを適切な HTTP 動詞にマッピングします。

サービスを定義したら、Apache CXF を使用して実装できます。

Apache CXF での REST の実装

Apache CXF は Java API for RESTFul Web Services(JAX-RS) の実装を提供します。JAX-RS は、アノテーションを使用して POJO をリソースにマップする標準化された方法を提供します。

抽象化サービス定義から JAX-RS を使用して実装された RESTful Web サービスに移行する場合は、次の操作を行う必要があります。

  1. サービスのリソースツリーの上部を表すリソースのルートリソースクラスを作成します。

    「ルートリソースクラス」 を参照してください。

  2. サービスの他のリソースをサブリソースにマッピングします。

    「サブリソースの使用」 を参照してください。

  3. 各リソースで使用される各 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 実装は、JSON (JavaScript Object Notation) を使用したデータ交換もサポートします。JSON は、Ajax 開発者が使用する一般的なデータ形式です。JSON と JAXB との間でデータをマーシャリングすることは、Apache CXF ランタイムによって処理されます。