REST と SOAP

REST と SOAP は、オンラインデータ送信に対する 2 つの異なるアプローチです。具体的にはどちらも、Web アプリケーション間のデータ通信を可能にするアプリケーション・プログラミング・インタフェース (API) の構築方法を定義します。Representational State Transfer (REST) は、一連のアーキテクチャ原則です。Simple Object Access Protocol (SOAP) は、World Wide Web Consortium (W3C) が管理する公式プロトコルです。主な違いは、SOAP はプロトコルであるが、REST はプロトコルではないという点です。通常、API は、開発者のユースケースや好みに応じて、REST または SOAP に準拠します。

REST は、軽量の Web サービスおよびモバイル・アプリケーションのニーズに合わせた一連のアーキテクチャ原則です。あくまでガイドラインであるため、これらの推奨事項の実装は開発者に任されています。

REST API へのデータのリクエストは、通常ハイパーテキスト転送プロトコル (一般に HTTP と呼ばれる) を介して送信されます。要求が受信されると、REST (RESTful API または RESTful Web サービスと呼ばれる) 用に設計された API は、さまざまな形式（HTML、XML、プレーンテキスト、JSON）でメッセージを返すことができます。JSON (JavaScript オブジェクト表記) は、(その名称にかかわらず) あらゆるプログラミング言語で読み取ることができ、人間も機械も読み取り可能で軽量であるため、メッセージ形式としてよく利用されています。このように、RESTful API はより柔軟で、セットアップが容易です。

アプリケーションが以下の 6 つのアーキテクチャ・ガイドラインに沿っている場合、そのアプリケーションは RESTful であり、RESTful アプリケーションには以下のものが必要です。

1. クライアント、サーバー、およびリソースで構成されるクライアントサーバー・アーキテクチャ。
2. クライアントとサーバー間の通信がステートレスであること。サーバーにクライアントのコンテンツが要求をまたいで保存されることはありません。セッション状態に関する情報はサーバーではなくクライアントが保持します。
3. クライアントとサーバー間のやりとりの一部を不要にするためのキャッシュ可能なデータ。
4. コンポーネント間で統一されたインタフェース。これにより、アプリケーションのニーズに固有の形式ではなく、標準化された形式で情報が転送されます。これは「REST のアーキテクチャスタイルを他のネットワークベースのスタイルと区別する中心的な機能」であると、REST の創始者である Roy Fielding 氏が説明しています。
5. 階層化されたシステム制約。クライアントとサーバー間のやりとりは、階層レイヤーによって仲介できます。
6. オンデマンドのコード。サーバーは、実行可能なコードを転送することでクライアントの機能を拡張できます (ただし可視性が低下するため、このガイドラインの準拠は必須ではありません)。

SOAP は標準プロトコルです。元々、異なる言語および異なるプラットフォームで構築されたアプリケーションが通信できるようにすることを目的に設計されました。これはプロトコルなので、組み込みのルールが適用され、複雑さとオーバーヘッドが増大し、ページのロード時間が長くなる可能性があります。しかし、これらの標準は組み込みのコンプライアンスも提供するため、エンタープライズシナリオに適しています。組み込みのコンプライアンス基準には、セキュリティ、原子性、一貫性、分離、および耐久性 (ACID) が含まれます。ACID は、信頼性の高いデータベース・トランザクションが確実に行われるようにする一連のプロパティです。

一般的な Web サービスの仕様は次のとおりです。

• Web サービスセキュリティ (WS-Security)：トークンと呼ばれる一意の識別子を通じてメッセージを保護および転送する方法を標準化します。
• WS-ReliableMessaging：信頼性の低い IT インフラストラクチャを介して転送されるメッセージ間のエラー処理を標準化します。
• Web サービスアドレッシング (WS-Addressing)：ルーティング情報をネットワーク内の奥深くに保持するのではなく、SOAP ヘッダー内のメタデータとしてパッケージ化します。
• Web サービス記述言語 (WSDL)：Web サービスの機能、およびそのサービスの開始と終了の場所を記述します。

SOAP API に送信されたデータ要求は、HTTP (Web ブラウザの場合)、SMTP (電子メールの場合)、TCP などの任意のアプリケーション・レイヤー・プロトコルを介して処理できます。しかし、要求が受信されると、SOAP メッセージは XML ドキュメント (人間も機械も読み取り可能なマークアップ言語) として返信される必要があります。完了した SOAP API への要求はブラウザでキャッシュできないため、API に再送信しない限り、後でアクセスすることはできません。

SOAP に準拠するレガシーシステムはまだ多いかもしれませんが、後発の REST が Web ベースのシナリオにおいて高速な代替手段と見なされることも少なくありません。REST は柔軟な実装を提供する一連のガイドラインであり、SOAP は XML メッセージングなどの特定の要件を持つプロトコルです。

REST API は軽量で、IoT (モノのインターネット)、モバイル・アプリケーション開発、サーバーレス・コンピューティングなどの先進的なコンテキストに最適です。SOAP Web サービスは、多くのエンタープライズのニーズに合わせた組み込みのセキュリティとトランザクション・コンプライアンスを提供しますが、それによってサービス自体は重くなります。また、Google Maps API などの多くのパブリック API は REST ガイドラインに準拠しています。

Red Hat は、オープンソースやオープンスタンダードを通じて、オンプレミスでもクラウドでも利用可能な、軽量で包括的なモジュール式 API ソリューションを提供します。このソリューションは、IT を最適化して柔軟性を向上し、価値提供を迅速にするという、大きな役目を果たします。