RESTfulアーキテクチャの長所と短所[非公開]

RESTの長所と短所に関して私が見た最も一般的な議論は、SOAPに関連する議論を組み立てる傾向があります。私も経験がありません。私は現在、自分の経験の不足が評価を難しくしている決定に直面しています。私は、いくつかのコンポーネント（主に所有者が複数のサイトを管理できる管理面）と、ユーザーがホストに保持されているデータとやり取りできる公開ユーザーインターフェイスを備えたアプリケーションの開発を始めています。後者の部分をどこでもホストし、RESTfulアーキテクチャを介して前者と通信できるようにすること、または両方のコンポーネントが同じホストに存在することを要求することの意味を評価する必要があります。RESTfulアーキテクチャを開発することの重要な意味は何ですか、特に次の分野での能力に関して：

1：セキュリティ2：パフォーマンス3：インターフェイスの複雑さ

編集：この質問への答えのいくつかを見て-私は明確にする必要があります。SOAPとの比較を探しているのではなく、RESTアプリケーションとすべてのコンポーネントが1つのホストに存在するアプリケーションの概要を探しているわけではありません。（しかし、それらの答えに感謝！）

これらの領域を考慮して、大まかな概要を説明することはできますが、あなたの結論を引き出すことはできません。2つのプロトコルが異なる2つの主要な領域があります。

• メッセージフォーマット
• サービス発見

メッセージ形式は最も理解しやすいです。要求と応答の両方のSOAPパッケージングは​​かなり重いです。ヘッダーセクションと本文セクションの両方を含むSOAPエンベロープがあります。ヘッダーをリクエストチェーン内の複数のフィルターで使用して、何らかの識別、承認などを実行できます。ただし、XMLの解析にはコストがかかり、システムのスケーラビリティに一定のペナルティが生じます。スタック内のSOAP処理レイヤーに依存する量。

サービスの発見は、おそらく最も多くの競合が発生する場所です。RESTはその性質上、予測可能なエンドポイントを提供し、リクエストのコンテンツは単純なHTTPリクエストです。利点は、追加のオーバーヘッドがないことです。エンドユーザーは、サイトのURL構造を理解すると、必要なことをどのように行うかをほとんど推測できます。もちろん、単純なセキュリティを意識した人々は、それを弱点とみなします。結局、SOAPでは、エンドポイントが何であるかを知るためにWSDLを消費する必要があります。もちろん、SOAPを使用すると、メッセージ形式全体が渡されるため、より標的を絞った攻撃を行うことができます。

指定したカテゴリ別に分類します。

セキュリティ

どちらも本質的に他より安全ではありません。適切なセキュリティ原則を使用します。

• 通信を暗号化する
• 処理する前に、ユーザーを認証して承認してください。
• 直接攻撃を避けるための優れたコーディング習慣
• そして、それはほんの短いリストです。

あいまいさを忘れないでください！=セキュリティ。

性能

生のパフォーマンスとスケーラビリティの両方が、単純なHTTPプロトコルに従う要求のためにRESTに移行します。ほとんどのSOAPスタックは、SOAPスタックのスケーラビリティを大幅に向上させるSAX解析（イベントベースの解析）を使用しますが、オーバーヘッドに測定可能な影響があります。SOAPには、XML解析のオーバーヘッドに加えて、通常のHTTP処理のオーバーヘッドがあります。RESTにはHTTP処理のオーバーヘッドがあります。

複雑

システムの観点からは、RESTが勝ちです。可動部品が少なく、リクエストチェーンがより少ないなどです。つまり、信頼性を高めるのが簡単です。

プログラマーの観点からは、使用しているIDEまたはフレームワークがSOAPを適切にサポートしていれば、SOAPが勝つことができます。基本的に、RESTを使用すると、前処理作業（認証/承認など）を実行する責任がありますが、SOAPを使用すると、プラグイン可能な処理チェーンを使用してその多くを達成できます。

私の好み

私はHTTPリクエストに非常に満足しており、Webの仕組みを知っています。結果として、RESTアプローチのほうが私にとってはより望ましい方法です。しかし、私のクライアントの一部がそれに不快であることを知っています。彼らは、REST対SOAPなどのセキュリティを非難するいくつかの業界記事を読みました。結局のところ、どちらのアプローチもセキュリティを保証しないということです。アプリケーションが必要なだけ安全であることを確認するのはあなたの責任です。明らかに、ソーシャルWebアプリケーションは、銀行や政府のシステムほどセキュリティを要求（または要求）しません。多くのSOAPスタックには、ある程度のセキュリティを提供するためにプラグインできるプロセッサが含まれていますが、それらを検索して適切な場所に配置するのは依然としてユーザーの責任です。

1. セキュリティ： HTTPSを使用します。これは両方に適用されます。
2. パフォーマンス：。RESTはCPUの負荷が少ない（解析、マーシャリング、アンラップが少ない）。また、RESTを使用したキャッシングは簡単です。
3. 複雑さ： RESTはセットアップの点ではるかに少ない要求で、結局はGET / POSTにすぎません。SOAPは、維持するためにより多くの管理（wsdlなど）を必要としますが、IDEがサポートしていれば少し簡単です。

RESTといくつかのコンテンツ/ MIMEタイプで同じことができると、SOAPは肥大化しすぎていると思います。また、SOAPは、ラッパーのラッピングの性質と、HTTPに限定されず、より一般的であるという事実のため、多くのオーバーヘッドをもたらします。IDEが適切にサポートしていて、HTTPを学習したくない場合は、SOAPを使用するのは魅力的です。しかし、私にとって、RESTははるかに使いやすく、はるかにWebフレンドリーです。

現在、使用する非常に優れたREST APIがあります。Javaに興味があるなら、Jax-RSは本当にクールです。一部の人々にとって、これはポルノのようなものです。

RESTの最大の利点は、RPCアーキテクチャから脱却することだと思います。RESTはプロセスではなくリソースを公開します。これにより、1つの部品の変更、改善、さらには障害が他の部品への限定的な（負の）影響しか与えない、疎結合システムを作成できます。

残念ながら、RESTの一般的な誤用は、内部データ構造を公開することです（最悪の場合、データベースのCRUDです）。そのため、安全に行うのは非常に困難です。「正しい」使用法は、処理しているシステムの一部に関連する高レベルのオブジェクトを公開し、矛盾がある場合はエラーステータスコードを自由に返すことです。

RESTで見過ごされがちなもう1つの部分は、ほとんどの動詞のi等性です。GETだけでなく、PUTとDELETEも1回または複数回適用された場合、まったく同じ結果になります（既に削除されている場合は404を返し、クライアントが同じPUTを実行している場合は「変更なし」）。これにより、堅牢なシステムと、セマンティクスの正確な解釈の相互依存性が低下します。

WS- *標準は、実際には、SOAP / HTTPを介したRPCの実行に関するものです。そのため、CORBAとJ2EEおよびそれらの前身についての考え方はすべて、XMLで同じ種類のことを行うことに主に移行しています。これは、型宣言とサービスコントラクト、メタデータ交換、宣言型セキュリティなどのようなものを意味します。すべての本当の「エンタープライズ」のもの。率直に言って、企業でも使いすぎです。

自分のようなインターネットWebアプリケーションを構築する人は、ほぼ確実にRESTfulアーキテクチャを使用する方が良いでしょう。ほぼすべてのプラットフォームで使用でき、使用する仕様のバージョンやツール固有の型変換の癖などを心配することなく簡単に使用できます。

現在のREST実装に対するSOAPの大きな利点は、SOAPがより簡単にツール化できることです。ほとんどのRESTfulクライアントでは、インターフェイスを理解して何らかのクライアントを作成する必要があります。SOAPの場合、wsdl.exeを指すだけでクラスが生成されます。