REST 対 SOAP — これはしばらく前から問題になっていました。実際のところ、これらは「Web サービスにどのようにアクセスするか」という同じ質問に対する 2つの答えに過ぎません。
しかし、どちらかを選択するのは意外と難しいものです。
SOAP (Simple Object Access Protocol) は、長い間使用されてきた標準ベースの Web サービス アクセス プロトコルです。 もともと Microsoft によって開発された SOAP は、頭字語が示唆するほど単純ではありません。
REST (Representational State Transfer) は、SOAP の欠点に対応して作成されたもう 1つの標準です。 これは、SOAP の問題を修正し、Web サービスにアクセスするためのより簡単な方法を提供することを目的としています。
GraphQL はどうですか？
もちろん、GraphQL は最近大きな飛躍を遂げました。これについては、他の記事で詳しく説明しています。 ただし、REST や SOAP ほど標準化されていないため、この記事ではこれら 2つに焦点を当てます。
SOAP も REST も、どちらのプロトコルを使うかを決める際には考慮すべき問題があります。
共通点
SOAP と REST は HTTP プロトコル上の共通点がありますが、SOAP は REST に比べてより厳格なメッセージングパターンのセットとなっています。SOAP のルールが重要なのは、それなしではどんなレベルの標準化も達成できないからです。アーキテクチャ スタイルとしての REST は、処理を必要とせず、自然と柔軟性が高くなります。SOAP も REST も、情報交換のために誰もが遵守することに同意した、確立されたルールに依存しています。
SOAP の概要
SOAP は、XML のみを使用してメッセージングサービスを提供します。Microsoft はもともと、DCOM (Distributed Component Object Model) や CORBA (Common Object Request Broker Architecture) といった、インターネット上ではうまく機能しない古い技術の代わりに SOAP を開発しました。これらの技術がうまくいかないのは、バイナリメッセージングに依存しているためです。SOAP が採用している XML メッセージングは、インターネット上で適切に機能します。
最初のリリース後、Microsoft は SOAP をインターネット技術特別調査委員会 (IETF) に提出し、そこで標準化されました。 SOAP は拡張をサポートするように設計されているため、WS-Addressing、WS-Policy、WS-Security、WS-Federation、WS-ReliableMessaging、WS-Coordination、WS-AtomicTransaction 、および WS-RemotePortlets など、他にも様々な頭字語や略語が関連付けられています。 実際、これらの標準のリストは Web サービス標準で見つけることができます。
重要なのは、SOAP は非常に拡張性が高いということですが、特定のタスクに必要な部分だけを使用します。たとえば、誰でも無料で利用できる公開 Web サービスを使用する場合、WS-Security はそれほど必要ありません。
難易度はプログラミング言語に依存
SOAP でリクエストを作成してレスポンスを受信するために使用される XML は、非常に複雑になる可能性があります。一部のプログラミング言語では、これらの要求を手動で作成する必要がありますが、SOAP はエラーに寛容ではないので問題になります。ただし、他の言語では、SOAP が提供するショートカットを使用できます。これらは、リクエストの作成とレスポンスの解析に必要な労力を軽減するのに役立ちます。実際、.NET 言語を使用する場合、XMLを見ることさえありません。
魔法の一部は、Web サービス記述言語 (WSDL) です。これは、SOAP に関連付けられている別のファイルです。 Web サービスの動作の定義を提供するため、Web サービスへの参照を作成すると、IDE はプロセスを完全に自動化できます。したがって、SOAP の使用の難しさは、使用する言語に大きく依存します。
組み込みのエラー処理
最も重要な SOAP 機能の 1 つは、組み込みのエラー処理です。 リクエストに問題がある場合、レスポンスには問題の修正に使用できるエラー情報が含まれています。 Web サービスを所有していない可能性があることを考えると、この特定の機能は非常に重要です。 そうでなければ、なぜ動作しないのかを推測するしかありません。 エラーレポートは標準化されたコードも提供するため、コード内の一部のエラー処理タスクを自動化できます。
興味深い SOAP 機能は、必ずしも HTTP トランスポートで使用する必要がないことです。 SOAP を Simple Mail Transfer Protocol (SMTP) 上で使用するための実際の仕様があり、他のトランスポート上で使用できない理由はありません。 実際、Python や PHP などの一部の言語の開発者は、まさにそれを行っています。
REST の概要
REST は、より軽量な代替手段を提供します。多くの開発者は、SOAP が煩雑で使いにくいと感じていました。例えば、JavaScript で SOAP を扱う場合、必要な XML 構造を毎回作成する必要があるため、単純なタスクを実行するために大量のコードを書くことになります。
REST では、XML を使ってリクエストを行う代わりに、（通常）シンプルな URL を使用します。状況によっては、追加の情報を提供する必要がありますが、REST を使用するほとんどの Web サービスは、URL アプローチの使用のみに依存しています。REST は、4 つの異なる HTTP 1.1 動詞 (GET、POST、PUT、DELETE) を使用してタスクを実行できます。
SOAP とは異なり、REST では XML を使用してレスポンスを提供する必要はありません。REST ベースの Web サービスには、データをCSV (コマンド区切り値)、JSON (JavaScript Object Notation)、RSS (Really Simple Syndication) で出力するものもあります。要するに、アプリケーションで使用している言語で簡単に解析できる形で、必要な出力を得ることができるのです。
SOAP と REST の選択について
自分で Web サービスを作る予定がないのであれば、どちらのプロトコルを使用するかはすでに決まっているかもしれません。Amazon のように、両方をサポートしている Web サービスは非常に少ないです。どちらのプロトコルを使用するかではなく、どちらの Web サービスがお客様のニーズに最も適しているかに焦点を当てて決定してください。
SOAP の利点
RESTと比較した場合、SOAPには以下のような利点があります。
- 言語、プラットフォーム、トランスポートに依存しない (REST では HTTP を使用する必要があります)
- 分散型エンタープライズ環境で適切に機能します (REST は直接のポイントツーポイント通信を想定しています)
- 標準化
- WS * 標準の形でビルド前の重要な拡張性を提供します
- 組み込みのエラー処理
- 特定の言語の製品で使用した場合の自動化
REST の利点
REST は、ほとんどの部分で使いやすく、柔軟性があります。 SOAP に比べて次の利点があります。
- Web サービスとやり取りするために高価なツールは必要ありません
- 学習コストが少ない
- 効率的 (SOAP はすべてのメッセージに XML を使用しますが、REST はより小さなメッセージ形式を使用できます)
- 高速 (大規模な処理は必要ありません)
- 設計思想が他の Web テクノロジーに近い
無料の Web サービスを探す
SOAP と REST のどちらが最適かを判断する最良の方法は、無料の Web サービスをいくつか試すことです。 独自の Web サービスを作ることは骨の折れる作業になる可能性があるため、他の誰かの努力を利用する方がはるかに優れています。 さらに、これらの無料の Web サービスを使用すると、組織のニーズを満たしていることに気付く場合があります。これらのサービスを使用すると、時間とお金の両方を節約できます。 いくつかのサービスをご紹介します。
■ https://dog.ceo/dog-api/
■ https://swapi.co/
■ https://graphical.weather.gov/xml/
■ https://swagger.io/
無料の Web サービスの使用に関する一般的な懸念の 1 つは、システムまたはネットワークに何らかの損害を与える可能性があるという認識です。 しかし、スクリプト、コード、またはバイナリデータではなく、彼らは通常あなたにテキストを送るので、リスクは小さいです。
もちろん、Web サービスが一夜にして消えてしまうという懸念もあります。 ほとんどの場合、それらは非常に安定しており、すぐに消えることはほとんどありません。 疑わしい場合は、インターネットの存在感が大きい組織の Web サービスを使用してください。 また、サービスを使用する前に、サービスについて簡単に調べてください。
簡単な REST の例
場合によっては、シンプルであることがベストです。 この場合、必要なのは URL だけなので、REST はほぼ同じくらい簡単です。 ブラウザーを開き、アドレスフィールドに
と入力します。 Enterキーを押します。
ブラウザに CSV 形式で出力が表示されます。
緯度、経度、指定した住所が表示されます。 この簡単なテストは、ほとんどの主要都市のほとんどの住所で機能します (ただし、地方の住所ではうまく機能しません)。 考え方としては、他の Web サービスで使用するために必要な緯度と経度を取得することです。 Web サービスと小さなグルーコードを組み合わせることで、わずかな労力で短時間で驚くべきことを実行する非常に興味深いアプリケーションを作成できます。 他の誰もが重労働をしています。 SoapUI などの使いやすいツールを使用して REST API をテストすることもできます。
簡単な SOAP の例
SOAP は、その性質上、多少の設定が必要ですが、それでも非常に簡単に使用できます。
この例では、Visual Studio を使用して Windows フォーム アプリケーションを作成することから始めます。 サンプルコードは C# を使用していますが、同じ手法が他の .NET 言語でも問題なく機能します (適合するようにコードを変更する必要があります)。 ここに示すように、ラベル、テキストボックス、およびボタンを追加します ([緯度] フィールドと [経度] フィールドは読み取り専用です)。
ここで自動化が活躍します。 Solution Explorer で [References (参照)] を右クリックし、コンテキストメニューから[Add Service Reference (サービス参照の追加)]を選択します。 [Add Service Reference] ダイアログボックスが表示されます。 アドレス フィールドに次のアドレスを入力します：http://rpc.geocoder.us/dist/eg/clients/GeoCoder.wsdl そして [Go] をクリックします。 名前空間フィールドに GeocoderService と入力します。 ダイアログボックスは、次のようになります。
[OK] をクリックします。 Visual Studioは、Geocoder をバックグラウンドで操作するために必要なコードを追加します。
この時点で、Web サービスを使用する準備が整いました。 ここに示すように、[Get Position (位置を取得)]ボタンにコードを追加するだけです。
private void btnGetPosition_Click(object sender, EventArgs e)
{
// Create the client.
GeocoderService.GeoCode_PortTypeClient Client =
new GeocoderService.GeoCode_PortTypeClient();
// Make the call.
GeocoderService.GeocoderResult[] Result =
Client.geocode(txtAddress.Text);
// Check for an error result.
if (Result != null)
{
// Display the results on screen.
txtLatitude.Text = Result[0].lat.ToString();
txtLongitude.Text = Result[0].@long.ToString();
}
else
{
// Display an error result.
txtLatitude.Text = "Error";
txtLongitude.Text = "Error";
}
}
コードは、クライアントを作成することから始まります。これは、Visual Studio (または SOAP をネイティブにサポートする他の環境) で使用するすべての Web サービスに共通の手順です。
クライアントを作成したら、それを使用して、Webサービスでサポートされているメソッドの1つを呼び出します。この場合、geocode() を呼び出して、使用するアドレスを渡します。呼び出しの結果は、Resultという名前の GeocoderResult 変数に保存されます。十分に具体的でない場合、単一のアドレスが複数の位置を提供する可能性があるため、この情報は配列として返されます。
エラーが発生しない (結果として戻り値が null になる) と仮定しましょう。この例では、優れた情報を提供したことを前提としているため、最初の結果エントリで見つかった情報を緯度と経度の出力に配置します。したがって、この例は REST と比較してそれほど複雑ではありませんが、ご覧のとおり、単純な例でもより多くの作業が必要です。
結論
ここにいくつかの収益があります。
1つ目の結論
1つは、REST と SOAP の問題に対する最終的な答えは、「場合による」ということです。 各プロトコルには明確な長所と短所があります。 SOAP と REST の選択は、使用するプログラミング言語、使用する環境、および要件によって決まります。 (そして、前述のように、この記事ではまだ GraphQL を方程式に取り入れていません。)
本当に前もって問題を回避したい場合は、状況の長所と短所をグラフ化し、数字で比較してください。
2つ目の結論
車輪を再発明する必要はないことを忘れないでください。 企業が既存の Web サービスを作成するために多額の費用を費やしている (そしてより良い仕事をしている) のを見るのは驚くべきことです。 可能な限り無料の代替品を探してください。 多くの場合、Web サービスの選択によって、プロトコルの選択も決まります。
3つ目の結論
Web サービスに SOAP と REST のどちらを選択する場合でも、API を徹底的にテストするようにしてください。 ReadyAPI には、API テストのニーズに対応する機能、パフォーマンス、セキュリティ、仮想化ツールの完全なスイートがあります。 API Testing Resource Centerで、RESTfulAPI をテストする方法を学ぶこともできます。
ReadyAPI – REST, SOAP などの Web API テストツール
この資料は、SmartBear の Blog で公開されている「SOAP vs REST. What’s the Difference?」の日本語参考訳です。
