Web サービス通信プロトコルとしての SOAP と REST の違いに関する記事を読んだことがありますが、SOAP に対する REST の最大の利点は次のとおりだと思います。
REST はより動的であり、UDDI (Universal Description、Discovery、および Integration) を作成および更新する必要はありません。
REST は XML 形式だけに限定されません。RESTful Web サービスは、プレーン テキスト/JSON/XML を送信できます。
ただし、SOAP はより標準化されています (例: セキュリティ)。
それで、私はこれらの点で正しいですか？
RESTvsSOAPは正しい質問ではありません。
RESTSOAP、とは異なり、プロトコルではありません。
RESTは、ネットワーク ベースのソフトウェア アーキテクチャのアーキテクチャ スタイルおよび設計です。
REST概念はリソースと呼ばれます。リソースの表現はステートレスでなければなりません。それは、いくつかのメディア タイプを介して表されます。メディア タイプの例にはXML、 、JSON、およびが含まれRDFます。リソースはコンポーネントによって操作されます。コンポーネントは、標準の統一インターフェースを介してリソースを要求し、操作します。HTTP の場合、このインターフェイスは標準の HTTP ops で構成GETさPUTれPOSTますDELETE。
@Abdulazizの質問は、RESTとHTTPがしばしば併用されるという事実を明らかにしています。これは主に、HTTP の単純さと、RESTful 原則への非常に自然なマッピングによるものです。
クライアントサーバー通信
クライアント/サーバー アーキテクチャでは、関心事項が非常に明確に分離されています。RESTful スタイルで構築されたすべてのアプリケーションも、原則としてクライアント サーバーでなければなりません。
ステートレス
サーバーへの各クライアント要求では、その状態が完全に表現されている必要があります。サーバーは、サーバー コンテキストやサーバー セッション状態を使用せずに、クライアントの要求を完全に理解できる必要があります。したがって、すべての状態をクライアントで保持する必要があります。
キャッシュ可能
キャッシュ制約を使用して、応答データをキャッシュ可能またはキャッシュ不可としてマークできるようにすることができます。キャッシュ可能としてマークされたデータは、同じ後続のリクエストへのレスポンスとして再利用できます。
統一インターフェース
すべてのコンポーネントは、単一の統一されたインターフェイスを介して対話する必要があります。すべてのコンポーネントの対話はこのインターフェースを介して行われるため、さまざまなサービスとの対話は非常に簡単です。インターフェースはそのまま！これは、実装の変更を個別に行うことができることも意味します。統一されたインターフェースは常に変更されないため、このような変更は基本的なコンポーネントの相互作用には影響しません。欠点の 1 つは、インターフェイスに固執することです。インターフェイスを変更することで特定のサービスに最適化を提供できたとしても、REST ではこれが禁止されているため、うまくいきません。ただし、明るい面としては、REST は Web 用に最適化されているため、REST over HTTP は非常に人気があります。
上記の概念は、REST の定義特性を表し、REST アーキテクチャを Web サービスなどの他のアーキテクチャと区別します。REST サービスは Web サービスですが、Web サービスは必ずしも REST サービスであるとは限りません。
RESTと上記の箇条書きの詳細については、REST 設計原則に関するこのブログ投稿を参照してください。
編集:コメントに基づいてコンテンツを更新する
REST ( REpresentational S tate Transfer )オブジェクトのREpresentational State is TransferredはRESTです。つまり、オブジェクトを送信するのではなく、オブジェクトの状態を送信します
。REST はアーキテクチャ スタイルです。SOAP のような多くの標準は定義されていません。REST は、データに対する CRUD 操作を処理するために、インターネット経由でパブリック API (Facebook API、Google Maps API など) を公開するためのものです。REST は、単一の一貫したインターフェースを介して名前付きリソースにアクセスすることに重点を置いています。
SOAP ( S imple Object Access Protocol ) SOAP
は独自のプロトコルを導入し、アプリケーション ロジック (データではない) の一部をサービスとして公開することに重点を置いています。SOAP は操作を公開します。SOAP は名前付き操作へのアクセスに重点を置いており、各操作はいくつかのビジネス ロジックを実装します。SOAP は一般にWeb サービスと呼ばれますが、これは誤解です。SOAP は Web とはほとんど関係がありません。REST は、URI と HTTP に基づいた 真のWeb サービスを提供します。
休む理由
application/xmlをapplication/json返し/user/1234.jsonます/user/1234.xml。なぜ石鹸？
すでに多くの回答で取り上げられている他の多くの中で、SOAP を使用するとコントラクト、サポートされる操作、複雑な型などを定義する WSDL を定義できることを強調します。SOAP は操作指向ですが、REST はリソース指向です。個人的には、社内のエンタープライズ アプリケーション間の複雑なインターフェイスには SOAP を選択し、外界とのパブリックでシンプルなステートレス インターフェイスには REST を選択します。
追加:
++ REST にアプローチするときによく犯す間違いは、REST を「URL を使用した Web サービス」と考えることです。REST を、SOAP のような別のリモート プロシージャ コール (RPC) メカニズムと考えてください。 XML 名前空間。
++ 逆に、REST は RPC とほとんど関係がありません。RPC はサービス指向であり、アクションと動詞に重点を置いていますが、REST はリソース指向であり、アプリケーションを構成するモノと名詞に重点を置いています。