RESTfulアーキテクチャの長所と短所
RESTの賛否両論に関して私が見た最も一般的な議論は、SOAPに関連してその議論を構成する傾向があります。私もどちらも経験がありません。現在、自分の欠けている決定に直面しています。私はいくつかのコンポーネント（主に所有者が複数のサイトを管理できるようにする管理面）と、ユーザーが保持しているデータを操作できるパブリックユーザーインターフェイスを備えたアプリケーションの開発を始めていますホスト上。私は、後者の部分をどこでもホストできるようにし、RESTfulアーキテクチャを介して前者と通信できるようにすることの影響を評価する必要があります。特に、次の領域でのキャパシティに関して：
1：セキュリティ2：パフォーマンス3：インターフェイスの複雑さ
編集：この質問への回答のいくつかを見て-私は明確にする必要があります。 SOAP-ではなく、RESTアプリケーションとすべてのコンポーネントが1つのホスト上にあるアプリケーションの概要を比較しています。これらの回答に感謝します。でも！）
これらの領域を考慮して、大まかな概要を説明できますが、あなたの結論を導き出すことはできません。 2つのプロトコルが異なる主な領域は2つあります。
- メッセージフォーマット
- サービスの発見
メッセージ形式が最も理解しやすいです。要求と応答の両方のSOAPパッケージはかなり重いです。ヘッダーと本文セクションの両方を含むSOAPエンベロープがあります。ヘッダーは、リクエストチェーン内のいくつかのフィルターで使用して、特定の種類の識別、承認などを実行できます。ただし、XMLは解析にコストがかかるため、システムのスケーラビリティに一定の不利益が生じます。どれだけが、スタックのSOAP処理レイヤーに依存します。
サービスディスカバリは、おそらく最も競合する場所です。 RESTは、その性質上、予測可能エンドポイントを提供し、リクエストのコンテンツは単純なHTTPリクエストです。利点は、追加のオーバーヘッドがないことであり、エンドユーザーは、サイトのURL構造を理解したら、必要なことをどのように行うかをほぼ推測できます。もちろん、初心者のセキュリティ意識の高い人はそれを弱点と見なします。結局のところ、SOAPでは、エンドポイントが何かを知るためにWSDLを使用する必要があります。もちろん、SOAPを使用すると、メッセージ形式全体が提供されるため、より的を絞った攻撃を行うことができます。
あなたが与えたカテゴリで分類：
セキュリティ
どちらも本質的に他より安全ではありません。適切なセキュリティ原則を使用します。
- 通信を暗号化する
- 処理する前に、ユーザーを認証および承認してください。
- 直接攻撃を回避するための適切なコーディング習慣
- そして、それは単なる短いリストです。
あいまいな！=セキュリティを忘れないでください。
パフォーマンス
単純なHTTPプロトコルに従う要求により、パフォーマンスとスケーラビリティはどちらもRESTになります。ほとんどのSOAPスタックは、SAX解析（イベントベースの解析）を使用します。これにより、SOAPスタックのスケーラビリティが大幅に向上しますが、オーバーヘッドに測定可能な影響があります。 SOAPには、XML解析のオーバーヘッドに加えて、通常のHTTP処理のオーバーヘッドがあります。 RESTには、HTTP処理のオーバーヘッドがあります。
複雑さ
システムの観点からは、RESTが優先されます。可動部分が少なく、リクエストチェーンがスリム化されています。つまり、信頼性を高めることが容易になります。
プログラマの観点から見ると、SOAPは、IDEまたは使用しているフレームワークが適切なサポートを提供している場合に勝つことができます。基本的に、RESTを使用すると、前処理作業（認証/承認など）を実行する責任があります。一方、SOAPを使用すると、プラグイン可能な処理チェーンでその多くを実行できます。
私の好み
私はHTTPリクエストに非常に慣れており、Webの仕組みを知っています。結果として、RESTアプローチの方が私にとってはより好ましい方法です。ただし、一部のクライアントはそれを不快に感じています。彼らは、RESTとSOAPなどのセキュリティを非難する業界の記事をいくつか読んだことがあります。結論として、どちらのアプローチでもセキュリティは保証されません。アプリケーションが必要なだけ安全であることを確認するのはあなたの責任です。明らかに、ソーシャルWebアプリケーションは、銀行や政府のシステムほど多くのセキュリティを要求（または希望）しません。多くのSOAPスタックには、プラグインしてある程度のセキュリティを提供できるプロセッサが含まれていますが、それらを検索して所定の場所に配置するのは、依然としてユーザーの責任です。
- セキュリティ：HTTPSを使用します。これは両方に当てはまります。
- パフォーマンス：。 RESTは、CPUコストが低くなります（解析、マーシャリング、アンラップが少なくなります）。また、RESTでのキャッシングは簡単です。
- 複雑さ：REST設定の点ではるかに少ない要求であり、結局のところGET/POSTです。SOAPを維持するには、より多くの管理が必要です（wsdlなど）が、IDEがサポートしている場合は少し簡単です。
[〜＃〜] soap [〜＃〜] は、RESTといくつかのコンテンツ/ MIMEタイプを使用して同じことを実行できる場合、肥大化しすぎると思います。また、SOAPは、ラッパーのラッピングという性質と、より一般的でHTTPに限定されないという事実により、多くのオーバーヘッドをもたらします。SOAP IDEが適切にサポートしていて、HTTPを学びたくない場合に使用します。しかし、私にとっては、RESTの方がはるかに使いやすく、もっとウェブフレンドリー。
現在、非常に優れたREST使用するAPIがあります。Javaを使用している場合、Jax-RSは本当にクールです。一部の人にとっては、 this はポルノのようです。
RESTの最大の利点は、RPCアーキテクチャから脱却することです。RESTは、プロセスではなくリソースを公開します。これにより、緩やかにバインドされたシステムを作成できます。変更、改善、ある部品の故障でさえ、他の部品への影響は限定的（マイナス）です。
残念ながら、RESTの一般的な誤用は、内部データ構造を公開することです（最悪の場合、それはデータベースのCRUDです）。それにより、veryになります。 「正しい」使用は、処理しているシステムの一部に関連する高レベルのオブジェクトを公開し、不整合があればエラーステータスコードを自由に返すことです。
RESTのよく見落とされるもう1つの部分は、ほとんどの動詞のべき等です。GETだけでなく、PUTおよびDELETEも、1回または数回適用するとまったく同じ結果になるはずです（すでに削除されている場合は404を返し、クライアントが同じものをPUTしている場合は「変更なし」を返します。これにより、堅牢なシステムが実現し、セマンティクスの正確な解釈の相互依存性が低下します。
WS- *標準は、実際にはほとんどがRPC over SOAP/HTTPの実行に関するものです。したがって、CORBAとJ2EE、およびそれらの前身にまで及んだすべての考え方は、ほとんどXMLで同じ種類のことをすることに移行しました。これは、型宣言とサービスコントラクト、メタデータ交換、宣言型セキュリティなどのことを意味します。これらすべてが本当の「エンタープライズ」のものです。率直に言って、それは企業内でも使いすぎです。
自分のようなインターネットWebアプリケーションを構築する人々は、RESTfulアーキテクチャを使用するほうが間違いなく良いでしょう。ほぼすべてのプラットフォームで使用でき、どのスペックのどのバージョンを使用しているか、無数のツール固有の型変換の癖などを気にすることなく、簡単に使用できます。
現在のSOAP実装よりもRESTの大きな利点は、SOAPがより簡単にツール化されることです-ほとんどのRESTfulクライアントはインターフェイスを理解し、ある種のクライアントを作成するために私は、SOAPの場合、wsdl.exeを指すだけで、クラスが生成されます。