SOAPとREST APIの違い

SOAP APIとは？

まずは、SOAPの基本を理解することから始めます。SOAPはSimple Object Access Protocolの略で、異なるプログラミング言語、ツール、プラットフォームで作られたプログラム間のデータ交換に安定性と一貫性をもたらすために設計されたAPI開発プロトコルです。 

SOAPは、シームレスなクライアントとサーバ間の通信を実現するために従うべき、国際的に認められた規則を提示します。SOAPリクエストはエンベロープ形式で送信され、このエンベロープにはリクエスト処理に必要な重要な情報が含まれます。通常、SOAPエンベロープの主要部分はヘッダーとボディ属性です。 

SOAPの基本的な特徴 

以下は、SOAPの特徴のいくつかです：

• SOAPはXMLを用いて構築され、ウェブサービス専用です。 
• SOAPメッセージは大量のデータを含むため、メッセージ処理に多くの帯域幅を消費します。 
• RESTではSOAPは使用されません。 

SOAPの利用場面

SOAPがAPI開発において重要な役割を果たすため、以下の場面での導入が有益です。

1. 同期処理とその後の呼び出しに使用する 

クライアントにアプリの信頼性や信頼性、およびAPIセキュリティの向上が求められる場合、最新のSOAP標準であるSOAP 1.2が役立ちます。SOAP 1.2は、シームレスかつ同期的な処理のための高度な機能を提供します。  

また、特定APIの後続呼び出しをサポートし、必要なセキュリティ対策も取り入れています。 

2. 公式な通信手段として利用する 
   

サーバとクライアントが既に特定の形式でデータを交換する準備が整っている場合、SOAP 1.2は厳格な仕様を多数備えているため、公式な通信手段として適しています。 

3. 有状態操作のシームレスな処理に利用する 
   

リクエスト間で状態を維持する必要があるアプリでは、SOAP 1.2を使用すると、既定のWS*構造が利用できるため、作業が迅速かつ簡単に行えます。 

SOAP APIの例 

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="https://www.example.com/soap-envelope/"
soap:encodingStyle="http://www.example.com/soap-encoding">
<soap:Header>
<m:Trans xmlns:m="https://www.example.com/transaction/"
  soap:mustUnderstand="a">bcd
</soap:Header>
<soap:Body>
  <m:GetEmployee xmlns:m="https://www.example.com/prices">
    <m:EName>Joe></m:EName>
  </m:GetEmployee>
</soap:Body>
</soap:Envelope>

SOAPの長所と短所 

SOAPの基本が理解できたところで、開発者が享受できるメリットとデメリットについて見ていきます。 

 長所  

• SOAPでは、開発者はWSDLを利用できます。WSDLは、ウェブサービスの手順やアクセス方法を説明する言語で、API利用を学ぶための包括的な情報源となり、API開発を円滑に進める助けになります。 
• 複数の拡張機能と連携する際には、SOAPは優れたツールです。WS Addressing、WS Security、WS Federationなどの拡張と連携することで、アプリの機能を強化できます。 
• SOAPはプロトコルに依存しないため、HTTP、SMTP、TCPなど様々なアプリプロトコルで利用可能です。そのため、幅広いユーザーが実践できます。  

短所  

• SOAPは優れた面もありますが、いくつかの面では不足があります。利用を検討する前に、期待外れとなる可能性のある点を理解することが大切です。 
• SOAPの最大の欠点は、ペイロードデータ転送にXMLを使用する点です。XMLは処理に通常より時間がかかり、パフォーマンスの問題を引き起こす可能性があります。 
• また、SOAPの複雑な構文も敬遠される理由の一つです。XMLのみで動作するため、エンベロープからデータを抽出・読み取るのに手間と時間がかかり、API開発の時間を延ばしてしまいます。  

REST APIとは？ 

REST（Representational State Transfer）は全く異なるアプローチです。現代のウェブベースのアプリ開発で広く採用されるアーキテクチャパターンであり、ファイル、オブジェクト、メディアなどの主要なアプリの構成要素を管理します。  

RESTで作られるAPIは、HTTPを介してウェブサイトやアプリの機能を提供し、GETやPOSTなどのHTTPメソッドに対応しています。 

REST APIはウェブ上で高い相互運用性を発揮するため、多くの利用者に選ばれています。 

RESTの基本的な特徴  

• RESTはユニフォーム・リソース・ロケーター（URL）を利用して、ハードウェアの各コンポーネントにアクセスします。 
• RESTは現代のアプリ基盤でのデータ通信の基本です。
• SOAPではRESTは利用できませんが、RESTはSOAPを利用することができます。RESTはあくまでアーキテクチャパターンであり、ウェブサービスの標準的な説明形式を持たないため、アプリ開発を完遂するにはSOAPが必要となる場合があります。  

RESTの利用場面

RESTの利点を最大限に活かすには、適切な場面での利用が重要です。以下はRESTが特に効果を発揮する例です。 

1. 帯域幅が制限されている場合に利用する 
   

前述の通り、SOAPメッセージは帯域幅を多く消費します。資源や帯域が限られている場合、RESTは頼りになる選択肢となり、ネットワーク帯域が制限されていても問題なく動作します。 

2. 状態管理が不要な場合に利用する
   

リクエスト間で状態を維持する必要がない操作は、RESTで正確に実行できます。 

3. 多数のリクエストのキャッシュが求められる場合に利用する
   

リクエストのキャッシュは重要な操作であり、正確に行う必要があります。RESTはキャッシュ機能を充実しており、同じリクエストの情報を複数回処理することが可能です。そのため、アプリ開発にかかる時間を短縮できます。 

4. コーディングが容易な場合に利用する
   

REST APIやサービスのコーディングはSOAPよりも簡素で、時間に制約がある場合や効果的なウェブアプリサービスを迅速に構築する必要がある場合に適しています。  

REST APIの例

以下にREST APIの例を示します：

{
"name": "XYZ",
"location": "India",
"title": “developer”,
joinYear: 2010
}

REST APIの呼び出しはHTTPリクエストを使用するため、よりシンプルです。先ほどと同様に顧客情報を取得する際、GETリクエストを用い、顧客名をURIで渡します。上記の例のRESTバージョンは以下の通りです。

GET https://example.com/customers?name=Michael

前述の通り、REST呼び出しは出力データをJSON形式だけで返します。そのため、結果も分かりやすくなります。この場合、出力は以下の通りです。

{ "name": "Michael", "level": “Premium”, "address": "Toronto" }

‍

RESTの長所と短所

長所

• RESTはSOAPよりも後に登場しましたが、利用者に多数のメリットを提供するため、注目されています。以下は、REST利用者が享受できる利点です。
• RESTはステートレスなパターンで、各ウェブサービス呼び出しで必要な情報をすべて含むため、他のコンテキストに依存しません。そのおかげで処理が高速化されます。 
• RESTで開発されたAPIは柔軟性が高く、サーバーからのデータをAtom、JSON、XMLなど複数の形式で取得できます。そのため、形式の利用に大きな自由度があります。 
• RESTではレスポンスをキャッシュすることが可能です。これにより、不要なバックエンド呼び出しを排除し、ウェブサービスのパフォーマンスが向上します。 

短所

• RESTは魅力的ですが、SOAPのような特定の国際的な標準が存在しないため、開発者が各自の判断で使用する結果、API開発が複雑になる可能性があります。 
• RESTにはいくつかのバリエーションが存在します。 
• RESTベースのアプリは、HTTPプロトコルに依存しており、それが制約となることもあります。  

‍

SOAPとRESTの例

SOAPとRESTの基本が理解できたところで、実際の例を見てみましょう。ここでは、サーバーから顧客情報（名前：Michael）を要求するシナリオです。

1. 例 - SOAPの利用例

SOAPリクエストを送信する際は、事前に定められた形式に沿ってXMLリクエストを作成する必要があります。リクエストを識別可能にするため、SOAPラッパーで包む必要があり、リクエストパラメータは次のようにフォーマットされます。

SOAP呼び出しのレスポンス形式は入力とほぼ同じですが、ボディには要求した詳細情報が含まれています。

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Header/>

<soapenv:Body>
<ns2:CustDetailsResponse xmlns:ns2="http://www.example.com/xml/customers">
<ns2:customer>
<ns2:name>Michael</ns2:name>
<ns2:level>Premium</ns2:level>
<ns2:address>Toronto</ns2:address>
</ns2:customer>
</ns2:CustDetailsResponse>
</soapenv:Body>

</soapenv:Envelope>

2. 例 - RESTの利用例

REST API呼び出しはHTTPリクエストを使用するため、よりシンプルです。先ほどと同様に顧客情報を取得する際、GETリクエストを用い、顧客名をURIで渡します。上記の例のRESTバージョンは以下の通りです。

GET https://example.com/customers?name=Michael

前述の通り、REST呼び出しは出力データをJSON形式だけで返します。そのため、結果も分かりやすくなります。この場合、出力は以下の通りです。

{ "name": "Michael", "level": “Premium”, "address": "Toronto" }

‍

REST APIのセキュリティ脆弱性

• ‍インジェクション攻撃

最も一般的で危険な攻撃の一つとして、保護されたAPIやアプリに悪意あるコードを挿入する手法があります。放置すると、脅威アクターによるメインシステムやアプリへの不正アクセス、不正な入力の挿入など深刻な結果を招く可能性があり、代表的なものにXSSやSQLインジェクションがあります。

• ‍認証破損

OAuthやAPIキーなど適切な認証対策が講じられていないAPIは、この脆弱性の対象となり、認証手順を回避されることで管理者権限での操作が可能になる恐れがあります。

• ‍〈strong id="">機密データの露出

保存中や利用中のAPIが適切に暗号化されていない場合、この攻撃の対象となります。軍用レベルの暗号化がなければ、脅威アクターにより銀行情報や個人情報などの機密情報が盗まれたり、不正に操作される危険があります。

• ‍〈strong id="">アクセス制御の破損

適切なアクセス制御が実施されていない場合、APIは容易に侵害され、ハッカーの意図により複数のアカウントへの不正アクセスやデータ交換の改ざんなどの問題が発生する恐れがあります。

• ‍HTTP及びTLS不備

TLSやHTTPの品質基準が整っていないAPIは、ハッカーにとって好都合な状態となります。TLS暗号化がないことは、MITM攻撃の好条件となります。

• ‍MITM攻撃

MiTM、すなわち中間者攻撃は、攻撃者がセキュアな通信に介在して不正利用する脆弱性を意味します。

• ‍パラメータ改ざん

価格や権限などの重要なパラメータを改ざんし、個人的な利益を得る目的で、通信中の情報を変更する攻撃です。

SOAP APIのセキュリティ脆弱性

• ‍DoS攻撃

DoS攻撃（Denial of Service）は、APIに対して大量のリクエストを送り、特定のAPIを利用不可能にする非常に一般的なサイバー脅威です。

• ‍XMLインジェクション（XXE）

しばしばSOAPインジェクションとも呼ばれるXXEは、不正なユーザー入力がサーバー側のSOAPメッセージやXML文書に転送されるケースです。XMLのメタ文字を用いて、攻撃者が既存のXMLを改ざんし、不正な活動を行います。

• ‍SQLインジェクション

攻撃者がアプリ生成のデータベースクエリを改ざんし、自分の意図通りに動作させる手法です。SOAP APIの場合、改ざんされたSQLクエリがAPI呼び出しに挿入されます。

• ‍XAMLインジェクション

XAMLというマークアップ言語に悪意あるコードを挿入する攻撃です。

• ‍コマンドインジェクション

この攻撃は、脆弱なユーザー入力がSOAP APIに転送されたときに発生し、攻撃者はAPIに対して意のまま操作できるようになります。

• ‍SOAPアクションのなりすまし

SOAPアクションのなりすまし、中間者攻撃は、サーバとクライアント間の通信に攻撃者を介在させ、盗聴やデータ窃盗などを行う手法です。

• ‍アクセス制御と認証の破損

適切なアクセスや認証の検証基準がないと、URLの改ざんやJSON Web Tokenの操作など、多くの問題が発生する可能性があります。

• ‍クロスサイトスクリプティング（XSS）

XSSは、APIによる通信が妨害される攻撃を意味し、サーバと脆弱なAPI間の通信が対象となります。

なぜRESTはSOAP Webサービスよりも速いのか？

前述の通り、SOAPは複雑で標準的な形式を採用しており、規則に従う必要があります。XMLは手間がかかり、処理に時間がかかります。 

一方、RESTはシンプルなJSON形式を利用し、情報のキャッシュにより通信時間を短縮するため、より速く目的に到達します。 

SOAPとREST API：どちらがより安全か？ 

どの手法を選ぶ際も、APIセキュリティは最優先すべき点です。RESTは速く扱いやすいですが、安全性ではSOAPが優れています。  

SOAPとRESTはいずれもAPI呼び出し時のデータ保護にSSL（Secured Socket Layer）を利用できます。しかし、SOAPはさらにWeb Services Securityもサポートし、APIセキュリティを強化して多くの問題を回避できます。したがって、APIセキュリティを重視する場合、SOAPのほうが優れています。  

RESTのSOAPに対する利点 

1. RESTは多数のデータ形式に対応しています。SOAPはXML以外の形式に対応していません。 
2. RESTはJSONと併用することで、複雑さを伴わずに利用できます。  
3. RESTの利用により、ブラウザクライアントは優れた技術サポートを享受できます。  
4. RESTのキャッシュ機能は動的かつ変更されないため、アプリのパフォーマンス向上に寄与します。 
5. RESTは一般的に使用され、Amazon、eBay、Google、Yahooなど多数の企業から高い評価を得ています。 
6. RESTは帯域幅が少なくても動作し、統合力にも優れるため、開発者はゼロから迅速に作業を完遂できます。その速さは機能性に悪影響を与えず、常に高品質です。 

‍

SOAPのRESTに対する利点 

1. SOAPは、通信失敗時に備えた再試行ロジックを既に搭載しており、これがRESTにはありません。通信が失敗した場合、再試行が唯一の選択肢となります。 
2. SOAPは高度に標準化され、一定の規則を提供するため、品質と標準の維持が容易です。一方、RESTには標準的な規則がありません。 
3. SOAPの標準HTTPプロトコルにより、複数のファイアウォールやプロキシを介しても、煩雑な変更を必要とせずに動作可能です。 
4. 拡張機能との互換性において、SOAPはWS-Addressing、WS-ReliableMessaging、WS-Coordinationなどと優れた連携が可能なため、他より有利です。 

SOAPとRESTの代替手段

多くの開発者が上記ウェブサービスをプロジェクトに利用していますが、IT業界は常に新しい技術や選択肢を模索しています。信頼性のある代替手段として、以下の選択肢があります。

• GraphQL

クライアントやユーザーへのデータ提供に多用されるクエリ言語であるGraphQLは、プロジェクトがC++、Python、JavaScriptなどに基づく場合に適した選択肢となります。開発元のFacebookは、データの取得、書き込み、サブスクリプションを非常に効率的に行えるよう設計しました。

GraphQLのメッセージ形式はJSONで、HTTPで動作します。この点からRESTに似ているとも言えますが、実際はさらにいくつかの面で優れています。例えば、一度の呼び出しで複数のリクエストを送信でき、操作の複雑さを軽減しつつ時間を節約できます。

• JSON

JSONは広く知られているオープンスタンダードで、データオブジェクトの送受信用として多くのアプリで利用されています。その主な利点は、軽量な形式により迅速なデータ送受信が可能な点です。このため、SOAPやRESTの代替手段としてJSONを提案します。

• gRPC

gRPCはGoogleのプロジェクトで、HTTP/2を基盤とする非常に現代的なシステムです。マイクロサービスベースのソリューションや高性能なアプリを実現する際、またエンドユーザーのモバイルデバイスとアプリのバックエンドサービスを接続する際にも活用できます。 

驚くべきことに、gRPCのデータやメッセージはJSONオブジェクトよりも軽量で、より多くの接続方法が提供されます。

‍

SOAPとRESTの比較表

以上で2つのウェブサービスの主要な詳細を見てきましたが、主要なポイントを簡単に比較したい場合、以下の比較表をご覧ください。

SOAPとRESTの代替手段

多くの開発者が上記ウェブサービスをプロジェクトに利用していますが、IT業界は常に新しい技術や選択肢を模索しています。信頼性のある代替手段として、以下の選択肢があります。

• GraphQL

クライアントやユーザーへのデータ提供に多用されるクエリ言語であるGraphQLは、プロジェクトがC++、Python、JavaScriptなどに基づく場合に適した選択肢となります。開発元のFacebookは、データの取得、書き込み、サブスクリプションを非常に効率的に行えるよう設計しました。

GraphQLのメッセージ形式はJSONで、HTTPで動作します。この点からRESTに似ているとも言えますが、実際はさらにいくつかの面で優れています。例えば、一度の呼び出しで複数のリクエストを送信でき、操作の複雑さを軽減しつつ時間を節約できます。

• JSON

JSONは広く知られているオープンスタンダードで、データオブジェクトの送受信用として多くのアプリで利用されています。その主な利点は、軽量な形式により迅速なデータ送受信が可能な点です。このため、SOAPやRESTの代替手段としてJSONを提案します。

• gRPC

gRPCはGoogleのプロジェクトで、HTTP/2を基盤とする非常に現代的なシステムです。マイクロサービスベースのソリューションや高性能なアプリを実現する際、またエンドユーザーのモバイルデバイスとアプリのバックエンドサービスを接続する際にも活用できます。 

驚くべきことに、gRPCのデータやメッセージはJSONオブジェクトよりも軽量で、より多くの接続方法が提供されます。

‍

SOAPとRESTの比較表

以上で2つのウェブサービスの主要な詳細を見てきましたが、主要なポイントを簡単に比較したい場合、以下の比較表をご覧ください。

結論

RESTとSOAPは、今日利用される最も人気のあるAPIプロトコルの一つです。RESTは扱いやすく一般的に利用されていますが、SOAPは標準化された規則を持っており、場合によっては有利です。いずれの手法を利用する場合でも、利用者や機密データ、内部システムの安全性を確保するために、適切な保護が必要です。OWASPトップ10は、セキュアなコードを作成するための効果的な第一歩です。REST、SOAP、その他のAPIプロトコルに対応した実行時APIセキュリティ層を追加することで、攻撃対象やリスクを最小限に抑えることができます。