SOAP と REST にはどのような違いがありますか?
SOAP と REST は 2 つのインターネットデータ交換メカニズムです。例えば、社内の会計システムが顧客の会計システムとデータを共有して請求タスクを自動化するとします。2 つのアプリケーションは、通信ルールを定義する API を使用してデータを共有します。SOAP と REST は API 設計における2つの異なるアプローチです。SOAP アプローチは高度に構造化されており、XML データ形式を使用します。REST はより柔軟性が高く、アプリケーションが複数の形式でデータを交換できるようにします。
SOAP と REST にはどのような類似点がありますか?
アプリケーションを構築するには、さまざまなプログラミング言語、アーキテクチャ、およびプラットフォームを使用できます。データ形式が異なるため、このようなさまざまなテクノロジー間でデータを共有することは困難です。SOAP と REST の両方がこの問題を解決しようとして登場しました。
SOAP と REST を使用して、さまざまなアプリケーション間の API や通信ポイントを構築できます。Web サービスと API という用語は同じ意味で使用されます。ただし、API はより広いカテゴリです。Web サービスは特別な種類の API です。
SOAP と REST には他にも類似点があります。
- どちらも、アプリケーションが他のアプリケーションからのデータリクエストをどのように行い、処理し、それに応えるかに関する規則と標準について説明しています
- どちらも標準化されたインターネットプロトコルである HTTP を使用して情報を交換します
- どちらも SSL/TLS をサポートし、安全で暗号化された通信を実現します
SOAP または REST のいずれかを使用して、安全でスケーラブルで耐障害性のある分散システムを構築できます。
SOAP API と REST API はどのように機能しますか?
SOAP は古いテクノロジーで、システム間の厳密な通信契約が必要です。テクノロジーの変化に対応するために、新しい Web サービス標準が徐々に追加されてきましたが、それによって追加のオーバーヘッドが発生します。REST は SOAP の後に開発され、その欠点の多くを本質的に解決しています。REST Web サービスは RESTful Web サービスとも呼ばれます。
SOAP API
SOAP は厳格な通信ルールを定義するプロトコルです。データ交換のあらゆる側面を管理するいくつかの関連規格があります。例えば、SOAP が使用する標準は次のとおりです。
- Web Services Security (WS-Security) は、トークンと呼ばれる一意の識別子を使用するなどのセキュリティ対策を指定します
- Web Services Addressing (WS-Addressing) には、ルーティング情報をメタデータとして含める必要があります
- WS-ReliableMessaging は、SOAP メッセージングのエラー処理を標準化します
- Web サービス記述言語 (WSDL) は、SOAP Web サービスの範囲と機能を記述します
SOAP API にリクエストを送信するときは、HTTP リクエストを SOAP エンベロープで囲む必要があります。これは、基になる HTTP コンテンツを SOAP リクエスト要件で変更するデータ構造です。エンベロープがあるため、TCP やインターネット制御メッセージプロトコル (ICMP) などの他のトランスポートプロトコルを使用して SOAP Web サービスにリクエストを送信することもできます。ただし、SOAP API と SOAP Web サービスは常に XML ドキュメントをレスポンスとして返します。
REST API
REST は、API がどのように機能するかについて 6 つの条件を課すソフトウェアアーキテクチャスタイルです。REST API が従う 6 つの原則は次のとおりです。
- クライアントサーバーアーキテクチャ。送信者と受信者は、テクノロジー、プラットフォーム、プログラミング言語などに関して互いに独立しています。
- レイヤード。サーバーには複数の仲介者が連携してクライアントのリクエストを完了させることができますが、それらはクライアントには見えません。
- 統一されたインターフェイス。API は、完全で十分に利用可能な標準形式でデータを返します。
- ステートレス。API は、以前のリクエストとは無関係に、すべての新しいリクエストを完了します。
- キャッシュ可能。すべての API レスポンスはキャッシュ可能です。
- オンデマンドのコード。API レスポンスには、必要に応じてコードスニペットを含めることができます。
REST リクエストを送信するには、GET や POST などの HTTP 動詞を使用します。Rest API のレスポンスは通常 JSON 形式ですが、データ形式が異なる場合もあります。
SOAP と REST のどちらを使うべきか?
SOAP と REST のどちらかを選択する前に、シナリオと API ユーザーの要件を検討してください。次の基準は検討する価値があります。
全体的なアプリケーション設計
モバイルアプリやハイブリッドアプリケーションなどの最新のアプリケーションでは、REST API の方がうまく機能します。REST は、マイクロサービスやコンテナなどの最新のアーキテクチャパターンを使用してアプリケーションを設計するためのスケーラビリティと柔軟性を提供します。ただし、すでに SOAP API が搭載されているレガシーシステムを統合または拡張する必要がある場合は、SOAP を継続したほうがよい場合があります。
セキュリティ
パブリック API はセキュリティ要件が低く、誰でも操作できるように柔軟性が求められます。そのため、パブリック API を構築する場合は REST の方が適しています。逆に、企業内部の要件 (コンプライアンスに関するデータレポートなど) 用のプライベート API の中には、SOAP の WS-Security の厳格なセキュリティ対策が役立つものもあります。
ACID 準拠
API ユーザーは、一連のトランザクションにわたって厳密な一貫性とデータ整合性を必要としていますか? 例えば、財務取引では、更新が 1 回でも失敗しても、データ更新のバッチ全体が失敗します。
SOAP には、原子性、一貫性、独立性、永続性 (ACID) に関するコンプライアンスが組み込まれています。また、SOAP はデータ整合性要件が高い場合に適しているかもしれません。この場合、REST API では、サーバーまたはデータベースレベルで状態を適用するために、追加のソフトウェアモジュールが必要になる場合があります。
主な相違点: SOAP と REST
SOAP はプロトコルですが、REST はアーキテクチャスタイルです。これにより、SOAP API と REST API の動作に大きな違いが生じます。
設計
SOAP API は関数またはオペレーションを公開しますが、REST API はデータ駆動型です。たとえば、他のアプリケーションが操作できる従業員データを含むアプリケーションを考えてみましょう。アプリケーションの SOAP API が CreateEmployee という関数を公開する可能性があります。従業員を作成するには、リクエストを送信するときに SOAP メッセージで関数名を指定します。
ただし、アプリケーションの REST API は /employees という名前の URL を公開する可能性があり、その URL への POST リクエストによって新しい従業員レコードが作成されます。
柔軟性
SOAP API は厳格で、アプリケーション間の XML メッセージングのみを許可します。また、アプリケーションサーバーは各クライアントの状態も維持する必要があります。つまり、新しいリクエストを処理するときは、以前のリクエストをすべて覚えておく必要があります。
REST の方が柔軟性が高く、アプリケーションはデータをプレーンテキスト、HTML、XML、JSON として転送できます。また、REST はステートレスなので、REST API はすべての新しいリクエストを以前のリクエストとは無関係に処理します。
パフォーマンス
SOAP メッセージは大きくて複雑なため、送信と処理が遅くなります。これにより、ページのロード時間が長くなる可能性があります。
REST はメッセージサイズが小さいため、SOAP よりも高速で効率的です。REST 応答もキャッシュ可能なため、サーバーは頻繁にアクセスされるデータをキャッシュに保存して、ページの読み込み時間をさらに短縮できます。
スケーラビリティ
SOAP プロトコルでは、アプリケーションがリクエスト間の状態を保存する必要があるため、帯域幅とメモリの必要量が増えます。その結果、アプリケーションは高価になり、スケーリングが困難になります。
SOAP とは異なり、REST ではステートレスで階層化されたアーキテクチャが可能なため、よりスケーラブルになります。例えば、アプリケーションサーバーはリクエストを他のサーバーに渡したり、仲介者 (コンテンツ配信ネットワークなど) に処理を許可したりできます。
セキュリティ
SOAP が HTTPS と連動するには、追加の WS-Security 層が必要です。WS-Security は追加のヘッダーコンテンツを使用して、指定されたサーバー内の指定されたプロセスだけが SOAP メッセージの内容を読み取れるようにします。これにより、通信のオーバーヘッドが増え、パフォーマンスに悪影響を及ぼします。
REST は追加のオーバーヘッドなしで HTTPS をサポートします。
信頼性
SOAP にはエラー処理ロジックが組み込まれているため、信頼性が向上します。一方、REST では、通信障害が発生した場合に再試行する必要があり、信頼性が低くなります。
SOAP と REST の相違点のまとめ
| SOAP |
REST |
|
| 以下の略です |
Simple Object Access Protocol |
Representational State Transfer |
| 内容 |
SOAP はアプリケーション間の通信用プロトコルです |
REST は通信インターフェイスを設計するためのアーキテクチャスタイルです。 |
| 設計 |
SOAP API はオペレーションを公開します。 |
REST API はデータを公開します。 |
| トランスポートプロトコル |
SOAP は独立しており、どのトランスポートプロトコルでも動作します。 |
REST は HTTPS でのみ動作します。 |
| データ形式 |
SOAP は XML データ交換のみをサポートします。 |
REST は XML、JSON、プレーンテキスト、HTML をサポートしています。 |
| パフォーマンス |
SOAP メッセージは大きくなるため、通信が遅くなります。 |
REST は、メッセージが小さく、キャッシュがサポートされているため、パフォーマンスが速くなります。 |
| スケーラビリティ |
SOAP はスケーリングが困難です。サーバーは、クライアントと交換した以前のメッセージをすべて保存することで状態を維持します。 |
REST は簡単にスケーリングできます。ステートレスなので、すべてのメッセージは以前のメッセージとは無関係に処理されます。 |
| セキュリティ |
SOAP は追加のオーバーヘッドを伴う暗号化をサポートします。 |
REST はパフォーマンスに影響を与えずに暗号化をサポートします。 |
| ユースケース |
SOAP はレガシーアプリケーションやプライベート API で役立ちます。 |
REST は最新のアプリケーションやパブリック API で役に立ちます。 |
AWS は API 要件をどのようにサポートできますか?
Amazon Web Services (AWS) は、お客様の API 要件をサポートするために Amazon API Gateway を提供しています。フルマネージド型サービスの API Gateway を利用すれば、開発者は規模にかかわらず簡単に API の作成、公開、保守、モニタリング、保護を行えます。API Gateway を使用すれば、リアルタイム双方向通信アプリケーション用の REST API を作成できます。
API Gateway を使用することで得られるメリットは次のとおりです。
- API リクエストとレスポンスの両方でユーザーに高速パフォーマンスを実現します。
- AWS Identity and Access Management (IAM) と Amazon Cognito を使用して API へのアクセスを許可できます。どちらのサービスもネイティブ OAuth サポートを提供します。
- 同時に同じ API の複数のバージョンを実行して、新しいバージョンをすばやく反復、テスト、リリースします。
- パフォーマンスメトリクスと API コール、データレイテンシー、およびエラー率に関する情報をモニタリングします。
今すぐ AWS アカウントを作成して、AWS で REST API の使用を開始しましょう。
