ウェブサービスの通信プロトコルとして、SOAPとRESTの違いについて書かれた記事を読んだことがあるが、SOAPに対するRESTの最大の利点は、次のようなものだと思う:
1.RESTはよりダイナミックで、UDDI(Universal Description, Discovery, and Integration)を作成・更新する必要がない。
2.RESTはXML形式だけに限定されない。RESTfulウェブサービスは、プレーンテキスト/JSON/XMLを送信できる。
しかし、SOAPはより標準化されている(例:セキュリティ)。
ということで、これらの点は正しいでしょうか?
残念ながら、RESTの周りには多くの誤った情報や誤解があります。あなたの質問と@cmdによる回答だけでなく、Stack Overflowのこのテーマに関連するほとんどの質問と回答がそれらを反映しています。 SOAPとRESTを直接比較することはできません。前者はプロトコルであり(少なくともそうであろうとしている)、後者はアーキテクチャスタイルだからです。なぜなら、前者はプロトコルであり(少なくともそうであろうとし)、後者はアーキテクチャスタイルだからだ。人々はSOAPでないHTTP APIをRESTと呼ぶ傾向があるので、これはおそらくこの辺りの混乱の原因の1つだろう。 物事を少し押し進め、比較を確立しようとすると、SOAPとRESTの主な違いは、クライアントとサーバーの実装間のカップリングの程度である。SOAPクライアントはカスタムデスクトップアプリケーションのように動作し、サーバーと緊密に結合している。クライアントとサーバーの間には厳格な契約があり、どちらかが何かを変更するとすべてが壊れることが予想されます。変更後は常にアップデートが必要ですが、契約が守られているかどうかを確認するのは簡単です。 RESTクライアントはブラウザに近い。プロトコルと標準化されたメソッドの使い方を知っている汎用的なクライアントであり、アプリケーションはその中に収まらなければならない。余分なメソッドを作ってプロトコルの標準に違反するのではなく、標準的なメソッドを活用し、それを使ってメディアタイプにアクションを作成するのです。正しく行われれば、カップリングは少なくなり、変更にもより優雅に対処できる。クライアントは、エントリーポイントとメディアタイプを除いて、APIに関する知識ゼロでRESTサービスに入ることになっている。SOAPの場合、クライアントは使用するものすべてに関する予備知識を必要とする。さらに、RESTクライアントは、サーバー自身から提供されるコード・オン・デマンドによって拡張することができる。典型的な例は、クライアント側で別のサービスとのインタラクションを駆動するために使用されるJavaScriptコードである。 これらが、RESTとは何か、SOAPとどう違うのかを理解するための重要なポイントだと思います:
stackoverflow.com/questions/<id>
というURIを取り、idをQuestion.idに置き換えて、それをブラウザに貼り付けなければならないと説明するでしょう。それはナンセンスですが、多くの人がRESTとはそういうものだと思っています。
この最後の点は、いくら強調してもしすぎることはありません。もしあなたのクライアントがドキュメントのテンプレートからURIを構築し、リソース表現にリンクがないのであれば、それはRESTではありません。RESTの作者であるRoy Fielding氏は、このブログの投稿でこのように明言している:REST APIはハイパーテキスト駆動でなければならない。
上記を念頭に置くと、RESTはXMLに限定されるものではないかもしれませんが、他のフォーマットで正しく行うには、リンクのフォーマットを設計し、標準化する必要があることに気づくでしょう。ハイパーリンクはXMLでは標準ですが、JSONでは標準ではありません。HAL]6のようなJSONのドラフト標準があります。
最後に、RESTは万人向けではありません。その証拠に、ほとんどの人はRESTと間違えて呼んだHTTP APIで問題をうまく解決し、それ以上には踏み出しません。RESTは時々、特に最初のうちは難しいが、サーバー側の進化が容易になり、クライアントが変更に強くなることで、時間の経過とともに報われる。もし何かを素早く簡単に行う必要があるのであれば、RESTを正しく使うことに悩む必要はありません。それはおそらくあなたが求めているものではないでしょう。何年も、あるいは何十年もオンラインでなければならないものが必要なら、RESTが向いている。RESTとSOAP
の比較は正しい質問ではない。
RESTはSOAP
と違ってプロトコルではありません。
REST`はネットワークベースのソフトウェアアーキテクチャのためのアーキテクチャスタイルでありデザインである。
RESTの概念はリソースと呼ばれる。リソースの表現はステートレスでなければならない。リソースは何らかのメディアタイプで表現される。メディア型の例としては
XML、
JSON、
RDFなどがある。リソースはコンポーネントによって操作される。コンポーネントは標準的な統一インターフェースを介してリソースを要求し、操作する。HTTPの場合、このインターフェースは
GET、
PUT、
POST、
DELETE` などの標準的なHTTP操作で構成される。
Abdulaziz'氏の質問は、REST
とHTTP
がしばしば併用されるという事実を明らかにしている。これは主にHTTPのシンプルさと、RESTfulな原則への非常に自然なマッピングによるものです。
クライアントサーバアーキテクチャには、非常に明確な関係分離があります。RESTfulなスタイルで構築されたすべてのアプリケーションは、原則としてクライアント-サーバーでなければなりません。
ステートレス。
クライアントからサーバーへの各リクエストは、その状態を完全に表現する必要がある。サーバーは、サーバーコンテキストやサーバーセッションのステートを使用することなく、クライアントリクエストを完全に理解できなければなりません。したがって、すべてのステートはクライアントに保持されなければならない。
**キャッシュ可能
キャッシュ制約を使用することができ、その結果、応答データをキャッシュ可 能またはキャッシュ不可能とマークすることができる。キャッシュ可能としてマークされたどのデータも、同じ後続リクエストに対する 応答として再利用することができる。
統一インターフェース
すべてのコンポーネントは単一の統一インターフェースを通して相互作用 しなければならない。すべてのコンポーネントの相互作用はこのインターフェイスを介して行われるため、異なるサービスとの相互作用は非常にシンプルです。インターフェイスが同じだからです!これはまた、実装の変更を分離して行うことができることを意味します。統一インターフェースは常に変更されないので、そのような変更は基本的なコンポーネントの相互作用には影響しません。デメリットとしては、インターフェイスから抜け出せないことだ。インターフェイスを変更することで特定のサービスに最適化を提供できたとしても、RESTはそれを禁止しているため、運が悪かったとしか言いようがない。しかし、良い面もある。RESTはウェブ用に最適化されているため、HTTP経由のRESTは驚くほど人気がある!
以上の概念は、RESTの定義的な特徴であり、RESTアーキテクチャをWebサービスなどの他のアーキテクチャと区別するものである。RESTサービスはウェブサービスであるが、ウェブサービスは必ずしもRESTサービスではないことに注意するとよい。
RESTと上記の箇条書きの詳細については、REST設計原則**に関するこのブログ投稿を参照してください。
*EDIT:コメントに基づいて内容を更新する**。
SOAP(*Simple Object Access Protocol*)とREST(Representation State Transfer**)はどちらもそれなりに美しい。だから、私は両者を比較しているのではない。その代わりに、私がRESTを使う方が好きな場合とSOAPを使う方が好きな場合のイメージを描こうとしているのだ。
**ペイロードとは何か?
インターネット上でデータが送信されるとき、送信される各ユニットには、ヘッダー情報と送信される実際のデータの両方が含まれます。ヘッダは、パケットの送信元と宛先を識別し、実際のデータはペイロードと呼ばれます。一般的に、ペイロードはアプリケーションに代わって運ばれるデータであり、宛先システムによって受信されるデータである。
さて、例えば、私は電報を送らなければならないが、電報のコストがいくつかの単語によって変わることは誰もが知っている。
*では、以下に挙げる2つのメッセージのうち、どちらの方が安く送れるのか教えてください。
<name>Arin</name>
それとも
"name": "Arin"
どちらも同じメッセージを表していますが、あなたの答えが2番目のものになることは分かっています。
つまり、JSONフォーマットでネットワーク経由でデータを送信する方が、ペイロードに関してはXMLフォーマットで送信するよりも安いと言いたいのです。
**これが、SOAPに対するRESTの最初の利点です。SOAPはXMLしかサポートしていませんが、RESTはテキスト、JSON、XMLなどさまざまなフォーマットをサポートしています。そして、Jsonを使えば、ペイロードに関しては間違いなく有利になることは、もうお分かりでしょう。
現在、SOAPはXMLしかサポートしていませんが、それにも利点があります。
**本当に!どんなふうに?
SOAPは3つの点でXMLに依存している。 エンベロープ - メッセージの中身と処理方法を定義します。
データ型のエンコーディング・ルール、そして最後にプロシージャー・コールとレスポンスのレイアウト。
このエンベロープはトランスポート(HTTP/HTTPS)を介して送信され、RPC(リモート・プロシージャ・コール)が実行され、エンベロープはXML形式のドキュメントで情報を返します。
重要な点は、SOAPの利点の1つは、「汎用」トランスポートを使用することですが、RESTはHTTP/HTTPSを使用するということです。SOAPはリクエストを送信するのにほとんどすべてのトランスポートを使用できますが、RESTはできません。SOAPを使う利点がここにあります。
上の段落ですでに述べたように、「RESTはHTTP/HTTPSを使う」ので、この言葉をもう少し深く掘り下げてみてください。
HTTP上のRESTについて話しているとき、HTTPに適用されているすべてのセキュリティ対策が継承されます。これはトランスポート・レベル・セキュリティとして知られており、電線の内側にある間だけメッセージを保護します。そしてもちろん、それらの段階はすべて、HTTPとは異なるものを使う可能性がある。
しかし、SOAPはRESTのようにSSLをサポートし、さらにWS-Securityもサポートします。WS-Securityは、メッセージの作成から消費までの保護を提供します。ですから、トランスポート・レベルのセキュリティについては、WS-Securityを使えば、どんな抜け穴があっても防ぐことができます。
それとは別に、RESTはHTTPプロトコルによって制限されているため、トランザクションのサポートはACIDに準拠していませんし、分散した国境を越えたリソース間で2相コミットを提供することもできません。
しかしSOAPは、短期間のトランザクションのためのACIDベースのトランザクション管理と、長期間のトランザクションのための補償ベースのトランザクション管理の両方を包括的にサポートしています。また、分散リソース間での二相コミットもサポートしている。
私は結論を出しているわけではないが、セキュリティやトランザクションなどが主な関心事である間は、SOAPベースのウェブサービスを好むだろう。
以下は、Java EE 6 Tutorial"で、以下の条件が満たされる場合、RESTfulな設計が適切である可能性があると述べられています。ご覧ください。
*私の回答を読んで楽しんでいただけたでしょうか。
REST ( RE プレゼンテーション S tate T 転送)。 RE プレゼンテーション S オブジェクトのテートは T 転送はRESTです。 オブジェクトは送信せず、オブジェクトの状態を送信します。 RESTは建築様式です。 SOAPのような多くの標準を定義していません。 RESTは、パブリックAPIを公開するためのものです(つまり、. Facebook API、Google Maps API)をインターネット経由でデータのCRUD操作を処理します。 RESTは、単一の一貫したインターフェースを介して名前付きリソースにアクセスすることに焦点を当てています。
SOAP ( S imple O bject A cess P rotocol)。 SOAPは独自のプロトコルを導入し、アプリケーションロジック(データではない)の一部をサービスとして公開することに焦点を当てています。 SOAPは操作を公開します。 SOAPは名前付き操作へのアクセスに焦点を当てており、各操作はいくつかのビジネスロジックを実装します。 SOAPは一般に webサービスと呼ばれますが、これは誤称です。 SOAPは、Webと関係があるとしてもごくわずかです。 RESTは、URIとHTTPに基づいて真の Webサービスを提供します。
なぜRESTなのか?。
-RESTは標準のHTTPを使用しているため、ほぼ完全に単純です。
-RESTは実装が簡単で、必要な帯域幅とリソースが少なくなります。
-RESTは、SOAPがXMLのみを許可するため、多くの異なるデータ形式を許可します。
-RESTは、JSONのサポートにより、ブラウザクライアントのサポートを強化します。
-RESTのパフォーマンスとスケーラビリティが向上しています。 RESTの読み取りはキャッシュでき、SOAPベースの読み取りはキャッシュできません。
-セキュリティが大きな関心事ではなく、リソースが限られている場合。 または、他の開発者が公に使用しやすいAPIを作成したい場合は、RESTを使用する必要があります。
-無国籍のCRUD操作が必要な場合は、RESTを使用します。
-RESTは、ソーシャルメディア、Webチャット、モバイルサービス、GoogleマップなどのパブリックAPIで一般的に使用されています。
-RESTfulサービスは、リクエストヘッダーパラメーター「Accept」に応じて、同じリソースに対してさまざまなMediaTypeを返します。POSTおよび「/ user / 1234.json」またはGET / user /の「application / xml」または「application / json」としてGET .1234.xml
GET用
-RESTサービスは、クライアント側のアプリケーションによって呼び出されることを意図しており、エンドユーザーは直接呼び出すことはできません。
- ST RESTは S tate T ransferから取得されます。 サーバーに保存する代わりに状態を転送すると、RESTサービスがスケーラブルになります。
なぜSOAPなのか?。
-SOAPの実装は非常に簡単ではなく、より多くの帯域幅とリソースが必要です。 -SOAPメッセージリクエストはRESTと比較して処理が遅く、Webキャッシングメカニズムを使用していません。 - WS-Security: SOAPはSSLをサポートしますが(RESTと同様)、一部のエンタープライズセキュリティ機能を追加するWS-Securityもサポートします。 - WS-AtomicTransaction:サービスに対するACIDトランザクションが必要です。SOAPが必要になります。 - WS-ReliableMessaging:アプリケーションに非同期処理と保証されたレベルの信頼性とセキュリティが必要な場合。 Restには標準のメッセージングシステムがなく、クライアントが再試行して通信障害に対処することを期待しています。 -セキュリティが大きな懸念事項であり、リソースが制限されていない場合は、SOAP Webサービスを使用する必要があります。 支払いゲートウェイ、金融および通信関連の作業用のWebサービスを作成する場合と同様に、ここでは高いセキュリティが必要なので、SOAPを使用する必要があります。
。。
休息と石 ⁇ の違い。
SOAP 。
1。 SOAPはプロトコルです。 2。 SOAPはSimple Object Access Protocolの略です。 3。 SOAPはプロトコルであるため、RESTを使用できません。 4。 SOAPはサービスインターフェイスを使用して、ビジネスロジックを公開します。 5。 SOAPは、厳密に従うべき標準を定義します。 6。 SOAPには、RESTよりも多くの帯域幅とリソースが必要です。 7。 SOAPは独自のセキュリティを定義します。 8。 SOAPはXMLデータ形式のみを許可します。 9。 SOAPはRESTよりも好ましくありません。
REST 。
1。 RESTは建築様式です。 2。 RESTは、州代表移管の略です。 3。 RESTは概念であり、HTTP、SOAPなどの任意のプロトコルを使用できるため、SOAP Webサービスを使用できます。 4。 RESTはURIを使用してビジネスロジックを公開します。 5。 RESTはSOAPのような標準を定義しすぎません。 6。 RESTはSOAPよりも少ない帯域幅とリソースを必要とします。 7。 RESTful Webサービスは、基になるトランスポートからセキュリティ対策を継承します。 8。 RESTでは、プレーンテキスト、HTML、XML、JSONなどのさまざまなデータ形式を使用できます。 9。 SOAPよりもRESTの方が好ましい。
詳細については、ここを参照してください。
私見あなたはSOAPとRESTを比較することができません。それらは2つの異なるものです。
SOAP はプロトコルであり、 REST はソフトウェアのアーキテクチャパターンです。 SOAP対REST のインターネットには多くの誤解があります。
SOAP は、Webサービス対応アプリケーションがインターネットを介して互いに通信するために使用するXMLベースのメッセージ形式を定義します。 そのためには、アプリケーションにメッセージ契約、データ型などの事前知識が必要です。.
REST は、URLからのサーバーの状態(リソースとして)を表します。無国籍であり、クライアントは、ハイパーメディアの理解を超えてサーバーと対話するための事前の知識を持つべきではありません。
まず第一に、正しい質問は「ウェブサービス+ WSDL + SOAP」対「REST」です。
- webサービスはルーズな意味で使用されますが、HTTPプロトコルを使用してWebページの代わりにデータ*を転送する場合、公式それはそのアイデアの非常に特定の形式です。 定義によれば、RESTは「Webサービス」ではありません。
ただし、実際には誰もがそれを無視するので、無視してみましょう。
すでに技術的な答えがあるので、直感を提供しようと思います。
他のプログラミング言語で実装されたリモートコンピューターで関数を呼び出すとします(これはしばしばリモートプロシージャ呼び出し/ RPC と呼ばれます)。 関数が、それを作成した人が提供する特定のURLで見つかると仮定します。 (どういうわけか)メッセージを送信し、何らかの応答を取得する必要があります。 したがって、考慮すべき2つの主要な質問があります。
-送信するメッセージの形式は何ですか。 -メッセージを前後に運ぶ方法。
最初の質問では、公式の定義はWSDLです。 これは、パラメーターとは何か、それらのタイプ、名前、デフォルト値、呼び出す関数の名前などを説明するXMLファイルです。 例WSDLは、ファイルが人間が読める(ただし簡単ではない)ことを示しています。
2番目の質問には、さまざまな答えがあります。 ただし、実際に使用されているのはSOAPだけです。 その主なアイデアは、以前のXML(実際のメッセージ)をさらに別のXML(エンコーディング情報やその他の役立つものを含む)にラップし、HTTP経由で送信することです。 HTTPのPOSTメソッドは、常に本文があるため、メッセージの送信に使用されます。
このアプローチ全体の主なアイデアは、 URLを関数にマップする、つまりアクションすることです。 したがって、一部のサーバーに顧客のリストがあり、それを表示/更新/削除する場合は、3つのURLが必要です。
-「myapp / read-customer」とメッセージの本文で、読まれる顧客のIDを渡します。
-「myapp / update-customer」と本文では、顧客のIDと新しいデータを渡します。
-myapp / delete-customer
と体内のID。
RESTアプローチでは、物事の見方が異なります。 URLはアクションを表すのではなく、 a物(REST用語ではリソースと呼ばれます)を表す必要があります。 HTTPプロトコル(すでに使用しています)は動詞をサポートしているため、これらの動詞を使用して、その上で実行するアクションを指定します。
したがって、RESTアプローチでは、顧客番号12はURL myapp / customers / 12
にあります。 顧客データを表示するには、GETリクエストでURLを押します。 削除するには、同じ URL、DELETE動詞を使用します。 更新するには、もう一度、POST動詞を含む同じ URLと、リクエスト本文の新しいコンテンツ。
サービスが真にRESTfulと見なされるために満たす必要がある要件の詳細については、Richardson成熟度モデルを参照してください。 この記事では例を示し、さらに重要なことに、(いわゆる)SOAPサービスがレベル0のRESTサービスである理由を説明します(ただし、レベル0はこのモデルへのコンプライアンスが低いことを意味し、不快ではなく、それでも有用です多くの場合)。
すでに多くの回答でカバーされている他の多くの中で、SOAPが契約、サポートされている操作を定義するWSDL、複雑なタイプなどを定義できることを強調します。 SOAPは運用を対象としていますが、RESTはリソースを重視しています。 個人的には、内部エンタープライズアプリケーション間の複雑なインターフェースにはSOAPを選択し、外部世界とのパブリックでシンプルでステートレスなインターフェースにはRESTを選択します。
。。
追加:
++ RESTに近づいたときにしばしば発生する間違いは、RESTを「URLを使用したWebサービス」と見なすことです。RESTをSOAPのような別のリモートプロシージャコール(RPC)メカニズムと考えるが、プレーンHTTP URLを介して呼び出され、SOAPの多額のXMLなしネームスペース。
++逆に、RESTはRPCとはほとんど関係がありません。 RPCはサービス指向でアクションと動詞に焦点を当てていますが、RESTはリソース指向であり、アプリケーションを構成するものと名詞を強調しています。