WSDLとRESTの長所と短所

関連：

なぜWebサービスの代わりにRESTを使用するのですか？

SOAPまたはREST（RESTfulな方法でHTTP / XMLを意味する）を使用してWebサービスを実装するかどうかを決定するとき、何に注意し、何を考えればよいですか？これは1つのサイズですべてに適合するわけではないので、どの方法を使用するかを選択するにはどうすればよいでしょうか。

2つのプロトコルは、現実の世界では非常に異なる用途を持っています。

SOAP（WSDLを使用）は、ドキュメントの受け渡しを中心としたヘビー級のXML標準です。これの利点は、リクエストとレスポンスが非常によく構造化され、DTDを使用することさえできることです。欠点は、XMLであり、非常に冗長であることです。ただし、これは、2つの当事者が厳密な契約（たとえば、銀行間通信）を必要とする場合に適しています。SOAPを使用すると、ドキュメントにWS-Securityなどを重ねることもできます。SOAPは通常、トランスポートに依存しません。つまり、必ずしもHTTPを使用する必要はありません。

RESTは非常に軽量で、HTTP標準に依存して動作します。便利なWebサービスをすばやく立ち上げて実行できるのは素晴らしいことです。厳密なAPI定義が必要ない場合は、これが適切な方法です。ほとんどのWebサービスはこのカテゴリに分類されます。APIをバージョン管理することで、APIを更新しても、古いバージョンを使用しているユーザーがそれを壊さないようにすることができます（バージョンを指定している限り）。RESTは基本的にHTTPを必要とし、フォーマットに依存しません（つまり、XML、JSON、HTMLなどを使用できます）。

豪華なWS- *機能は必要ないため、通常はRESTを使用します。SOAPは、WSDLを使用してWebサービスをコンピューターに理解させる場合に適しています。REST仕様は通常、人間が読める形式のみです。

次のリンクは、WSDLとRESTに関する有益な情報を提供しています。

いくつかの重要な点は

1）SOAPは分散コンピューティング環境向けに設計されており、RESTはポイントツーポイント環境向けに設計されています。

2）WADLを使用してRESTサービスのインターフェースを定義できます。

http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and -wadl

WSDL（「SOAP」を意味する）を「重い」と見なしている。重い問題はどうですか？ツールセットがすべての「重い作業」を実行している場合、なぜそれが重要なのでしょうか。

複雑なREST APIを使用する必要はまだありません。私がそうするとき、私はツールが一連のプロキシクラスに喜んで変換するWSDLが欲しいと思うので、メソッドのように見えるものを呼び出すことができます。代わりに、重要なRESTベースのAPIを使用するには、大量の「軽量」コードを手動で作成する必要があると思います。

それがすべて終わったとしても、人間が読めるドキュメントをコードに翻訳し、人間がそれを間違って読むという付随するリスクをすべて伴うことになります。WSDLは機械で読み取り可能なサービスの記述であるため、「間違って読み取る」ことははるかに困難です。

注：この投稿以降、私は適度に複雑なRESTサービスを使用する機会を得ました。確かに、私はWSDLまたは同等のものを望みました。そして、確かに、多くのコードを手作業で書かなければなりませんでした。実際、開発時間のかなりの部分は、さまざまなサービス操作を「手動で」呼び出すすべてのコードのコードの重複を削除するために費やされました。

これはおそらく上記のいくつかの投稿のコメントとして本当に属していますが、まだそれを行う担当者がいません。

SOAPとRESTに関してしばしば引用される多くの長所と短所が（IMO）2つのテクノロジーの実際の値または制限とほとんど関係がないことは興味深いと思います。おそらく最も引用されているRESTのプロは、それが「軽量」であるか、より「人間が読める」傾向があるということです。あるレベルでこれは確かに本当です、RESTはエントリへの障壁が低くなります-SOAPよりも必要な構造が少ないです（良いツールが主にここでの答えであると私が同意しているにもかかわらず-SOAPツールのあまりにも悪いかなり恐ろしい）。

ただし、その初期エントリコストを超えて、RESTの印象は、リクエストURLの形式とほとんどのRESTサービスによって交換されるデータの複雑さの組み合わせに由来すると思います。RESTは、より単純で人間が読めるリクエストURLを奨励する傾向があり、データも同様にダイジェスト可能です。ただし、これらはRESTにどの程度固有のものであり、どれだけ偶然のものであるかを示します。より単純なURL構造はアーキテクチャの直接の結果ですが、SOAPベースのサービスにも同様に適用できます。消化しやすいデータは、定義された構造がないために発生する可能性が高くなります。これは、データ形式をシンプルに保つことをお勧めします。そうしないと、多くの作業に参加することになります。SOAPの追加構造です。

したがって、コンピューターシステム間の構造化データの交換で使用する場合、RESTが本質的にSOAP（またはその逆）よりも優れているかどうかはわかりませんが、それらはまったく異なります。上記のRESTとSOAPの動的型と静的型の比較は良いものだと思います。動的言語が問題に遭遇する傾向があるのは、システムの長期的なメンテナンスと維持です（長期的には、1年または2年は話していませんが、5または10は話します）。RESTが時間の経過とともに同じ課題に直面するかどうかは興味深いことです。私は、分散情報処理システムを構築している場合、通信メカニズムとしてSOAPに引き付けられると考えがちです（これは、前述のように、送信とアプリケーションプロトコルの階層化と柔軟性により実現されます）。

他の場所ではRESTがより適切と思われます。（ペイロードに関係なく）クライアントとサーバー間のAJAXは、1つの主要な例です。私はこのタイプの接続が長持ちすることをあまり気にしていません。使いやすさと柔軟性は最低限です。同様に、外部サービスにすばやくアクセスする必要があり、時間の経過に伴うインタラクションの保守性を気にするつもりがなかったと考えた場合（ここでも、RESTが私にコストをかけることになると想定しています）または別の方法で）、それから私はRESTを選択するかもしれません。

いずれにせよ、これらはどちらも実行可能なテクノロジーであり、特定のアプリケーションに対してどのようなトレードオフを実現したいかに応じて、適切に（または不十分に）提供できます。

RESTはプロトコルではありません。それは建築様式です。または、必要に応じてパラダイム。つまり、SOAPの定義はかなり緩くなっています。基本的なCRUDの場合、Atompubなどの標準プロトコルを利用できますが、ほとんどのサービスでは、それ以上のコマンドを使用できます。

消費者としてのSOAPは、言語サポートに応じて、祝福と呪いのどちらにもなります。SOAPは厳密に型指定されたシステムで非常にモデル化されているため、静的に型指定された言語で最適に機能します。動的言語の場合、それは簡単に無用で不要になる可能性があります。さらに、クライアントライブラリサポートは、Javaや.NET以外ではそれほど良くありません。

私にとって、Webサービスという言葉を使用するときは注意が必要です。ここでは、SOAP Webサービス、REST Webサービス、またはその他の種類のWebサービスのいずれについて話すかを常に指定する必要があります。ここではさまざまなことについて話しているため、すべてのWebサービスに名前を付けても、人々はもう理解できません。

基本的に、SOAP Webサービスは長年にわたって非常に確立されており、SOAP仕様に基づいてそれらと通信する方法を記述する厳密な仕様に従っています。REST Webサービスは少し新しくなり、通信プロトコルを使用していないため、基本的にはシンプルに見えます。基本的に、REST Webサービスを使用するときに送受信するのはプレーンXMLです。SOAPのようなより洗練された通信プロトコルを扱う必要なく、XMLを思い通りに解析できるので、人々はそれを気に入っています。

私にとってRESTサービスは、SOAP Webサービスの代わりにサーブレットを作成するようなものです。サーブレットはデータを受け取り、データを返します。データのフォーマットはXMLベースです。必要に応じて、xml以外のものを使用することもできます。たとえば、タグはxmlの代わりに使用でき、それはもうRESTではなく何か他のものになります（xmlは本質的に軽量ではないため、重量の点でさらに軽量になる可能性があります）。それをWebサービスと呼びますか？はい、できますが、それは現在の標準に準拠しません。すべてのWebサービスの呼び出しを開始する場合、これがここでの主な問題ですが、やりたいことを行うことができ、その後、相互運用性の側面を失うことになります。つまり、Webサービスと交換されるデータの形式は、もはや標準化されていません。

SOAPが嫌いなのは、SOAPを理解するのが難しく、クエリを手動で生成できないことです。コンピューターはそれを非常にうまく行うことができるので、ここで明確にする必要があります。Webサービスのクエリと応答はエンドユーザーが直接使用することになっていますか、それともWebサービスは、正規化されたコンピューターシステムによって呼び出されるAPIの下にあることに同意しますか標準？

SOAP：SMTPを介して転送することもできます。つまり、電子メールの単純なテキスト形式を使用してサービスを呼び出すことができます。

SOAPメッセージをさまざまな言語のそれぞれのオブジェクト構造に変換するには、Webサービスコンシューママシンにフレームワーク/エンジンを追加する必要があります。

REST：WSDL2.0がREST Webサービスの記述もサポートするようになりました

携帯電話、PDAなどのモバイルデバイスからの呼び出しなど、サービスを軽量化する場合に使用できます。

システムが企業内に限定されているエンタープライズシステムの場合、クライアントをほとんど制御できるため、石鹸を使用するのがより簡単で適切です。クラス（プロキシ）を作成し、Javaまたは.net環境（ほとんどの企業で使用されている）に一致する通常のOOPを実行しているように見えるさまざまなツールがあるため、簡単です。

クライアントがjavascriptsやhtmlなど、タイピングが厳密でないものを使用している可能性があるため、インターネット向けアプリケーション（REST）を使用してインターフェース（Twitter APIなど）を公開します。RESTがよりリベラルであることは、より理にかなっています。

また、インターネット向けクライアント（World Wide Web）の場合、SOAPインターフェースからの純粋なxmlよりも、残りのインターフェースからのjsonまたはxmlを解析する方が簡単です。javascriptでプロキシを使用するのは難しく、javascriptは当然オブジェクトをサポートしていません。JavaScriptでRESTを使用している場合、通常はjson文字列を解析するだけでよいのです。インターネットに面するインターフェースは通常、非常に単純で（ほとんどの場合、その単純な解析）、一貫性を要求しないため、RESTで十分です。

エンタープライズアプリケーションの場合、トランザクション、セキュリティ、厳密な型指定、スキーマはエンタープライズアプリケーションの開発で非常に重要であり、SOAPが適しているため、RESTは適切ではないと思います。

私の結論は、SOAPはエンタープライズシステム用であり、RESTはインターネットまたはWWW用であるということです。互換性のある方法で使用することもできますが、最終的には適切なツールをジョブに使用するのが難しい場合があります。

私の悪い英語をごめんなさい。

RESTを守るために、HTTPとアドレス可能度の原則に厳密に従っています。たとえば、読み取り操作はGETを使用し、更新操作はPOSTを使用します。これははるかにクリーンなアプローチであると思います。Oreillyの本「RESTful Webサービス」では、これが私よりもはるかによく説明されています。読んだ場合、RESTアプローチを好むと思います

クライアント側のツールセットは1つです。そして、SOAPサービスに精通していること。ますます多くのサービスがRESTfulなルートを進んでおり、そのようなサービスのテストは簡単なcURLの例で行うことができます。ただし、両方の方法を実装してクライアントからの幅広い利用を可能にすることはそれほど難しいことではありません。

いずれかを選択する必要がある場合は、RESTをお勧めします。

これまでの回答には多くの情報が含まれていますが、指摘されていない哲学的な違いがあると思います。SOAPは、「RPCの後継である、オブジェクト指向でプラットフォームとプロトコルに依存しない現代的なものをどのように作成するか」に対する答えでした。RESTは、「WebでHTTPを成功させるための洞察を、分散コンピューティングにどのように使用するか」という質問から発展しました。

SOAPは、分散プログラミングを...プログラミングのように見せるためのツールを提供することです。RESTは、分散インターフェースを単純化するスタイルを課そうとするため、分散HTMLページが相互に参照できるように、分散リソースが相互に参照できます。これを行う1つの方法は、リソースの操作（大部分）を「CRUD」に制限しようとすることです（作成、読み取り、更新、削除）。

RESTはまだ若いです-「人間が読める」サービスを指向していますが、イントロスペクションサービスなどやプロキシの自動作成を除外していません。ただし、これらは（私が書いているように）標準化されていません。SOAPはこれらの機能を提供しますが、（IMHO）はこれらの「唯一の」機能を提供しますが、RESTによって課されたスタイルは、その単純さのためにWebサービスの普及を促進しています。私は、使用する必要のある特定のSOAP提供機能がない限り、初心者サービスプロバイダーがRESTを選択することを奨励します。

私の意見では、「グリーンフィールド」APIを実装していて、考えられるクライアントについてあまり知らない場合は、RESTを奨励するスタイルとして、インターフェースをわかりやすく、簡単に開発できるようにする傾向があります。クライアントとサーバーについてよく知っていて、両方を使いやすくする特定のSOAPツールがある場合は、RESTについては信心深くありません。

構成設定を変更するだけで、WSDLを発信するWCF Webコンポーネントを他の用途に簡単に移行できます。コードを変更せずに、HTTPを経由して名前付きパイプ、tcp、カスタムプロトコルなどを実行できます。WCFコンポーネントは、セキュリティ、双方向通話、トランザクション、同時実行性などの設定も簡単になると思います。

RESTはHTTPにかなり制限します（多くの場合これで問題ありません）。

私はこの議論が古いものであることを知っていますが、すべての回答を読んでコメントした後、2つのシステムの違いに関する最も重要なポイントを誰もが見逃したと思います。SOAPは複合型を使用してデータを提供するだけでなく、検証しますそれを定義し、厳密な型指定で保持します。WSDLは、データ形式、データ型、およびreg-exパターンスタイルのルールの追加を許可し、データの一部が要求/応答で許可される回数、および許可される回数を定義します。 。一方で、これらのメカニズムはありません。

SOAPは複雑で重い階層データを送信できるため、複雑で重いものです。RESTはプレーンテキストであり、起点と終点でルールを分類します。

SOAPは、ドキュメントに埋め込まれたすべてのデータルールを備えているため、ビジネスに依存しません。

SOAPとRESTの違いは、SOAPは自己完結型のビジネス指向スキーマであることです。RESTはテキストドキュメントです。