NetflixまたはTwitterスタイルのWebサービスでは、RESTまたはSOAPを使用する必要がありますか？
TwitterとNetflixの2つのRESTサービスを実装しました。どちらの場合も、これらのサービスをSOAPではなくRESTとして公開するという決定に関係する使用とロジックを見つけるのに苦労しました。誰かが私に不足しているものを教えてくれて、RESTがこれらのようなサービスのサービス実装として使用された理由を説明してくれることを願っています。
RESTサービスの実装は、SOAPサービスの実装よりも無限に長くかかります。すべての最新の言語/フレームワーク/プラットフォーム用のツールがあり、WSDLを読み取り、プロキシクラスとクライアントを出力します。 RESTサービスの実装は手作業で行われ、ドキュメントを読むことで取得されます。さらに、これらの2つのサービスを実装する際に、実際のスキーマまたは参照ドキュメントがないため、パイプを介して戻るものについて「推測」する必要があります。
とにかくXMLを返すRESTサービスを書くのはなぜですか？唯一の違いは、RESTを使用すると、各要素/属性が表す型がわからないことです。それを実装するのは自分で行い、hopeその日は文字列がありませんあなたはいつもintだと思っていた分野に出くわします。 SOAPはWSDLを使用してデータ構造を定義するため、これは簡単です。
SOAPを使用すると、SOAPエンベロープの「オーバーヘッド」があるという苦情を聞きました。今日、私たちは本当に少数のバイトを心配する必要がありますか？
RESTを使用すると、ブラウザにURLをポップしてデータを表示できるという議論を聞いたことがあります。もちろん、RESTサービスがシンプル認証を使用しているか、認証を使用していない場合。たとえば、NetflixサービスはOAuthを使用します。これには、リクエストを送信する前に、物事に署名し、物事をエンコードする必要があります。
各リソースに「読み取り可能な」URLが必要なのはなぜですか？ツールを使用してサービスを実装している場合、実際のURLを本当に気にしますか？
炭鉱のカナリア。
私はこのような質問を1年近く待っていました。この日が来ることは避けられませんでしたし、今後数か月のうちにこのような質問がさらに多く出てくると確信しています。
警告サイン
間違いなく、RESTfulクライアントの構築には、SOAPクライアントよりも時間がかかります。SOAPツールキットは、多くの定型コードを取り除き、クライアントプロキシオブジェクトを利用可能にしますVisual StudioなどのツールとサーバーURLを使用すると、5分以内にローカルで任意の複雑さのリモートオブジェクトにアクセスできます。
Application/xmlおよびapplication/jsonを返すサービスは、クライアント開発者にとって非常に迷惑です。そのデータのblobで何をすることになっていますか？
幸いなことに、RESTサービスを提供する多くのサイトは、クライアントライブラリの束も提供しているため、これらのライブラリを使用して、強く型付けされたオブジェクトの束にアクセスできます。彼らはSOAPを使用して、これらのプロキシクラスを自分でコード生成できました。
SOAPオーバーヘッド、ha。レイテンシーが死にます。人々が実際に回線を通過する余分なバイト数を心配しているのであれば、おそらくHTTPは正しい選択ではないでしょう。 user-agentヘッダーで使用されるバイト数を見ましたか？
ええ、HTMLやjavascript以外のデバッグツールとしてWebブラウザを使用したことがありますか。それは最悪だと信じてください。使用できる動詞は2つだけです。キャッシングは常に邪魔になり、エラー処理は非常に多くの情報を飲み込み、絶え間ないfavicon.icoを常に探しています。撃て。
読み取り可能なURL。名詞のみ、動詞なし。ええ、CRUD操作のみを行い、オブジェクトの階層に1つの方法でアクセスする必要がある限り、これは簡単です。残念ながら、ほとんどのアプリケーションにはそれ以上の機能が必要です。
差し迫った災害
現在、RESTサービスと統合するアプリケーションを開発している開発者のメトリックボートロードがあります。これらのサービスは、同じ結論に到達する過程にあります。進化と偶然の再利用の聖杯、ウェブ自体の特性、物事がどのようにうまくいかないか。
しかし、彼らはバージョニングが同じくらい問題であることを発見していますが、コンパイラは問題の検出を助けません。手書きのクライアントコードは、データ構造が進化し、URLがリファクタリングされるため、維持するのが面倒です。名詞と4つの動詞だけでAPIを設計するのは非常に困難です。特に、RESTful Urlの熱狂者がクエリ文字列を使用できる場合と使用できない場合を教えてくれます。
開発者は、Json形式とXml形式の両方をサポートするために努力を無駄にしている理由を尋ね始めます。
物事はどうしてそんなにうまくいかなかった
何が悪かったのかを説明します。開発者である私たちは、マーケティング部門に私たちの主な弱点を利用させます。銀の弾丸を永遠に探し求めた結果、RESTが本当である。現実的にはRESTはとても簡単でシンプルだ。 GET、PUT、POSTおよびDELETEを使用します。地獄、私たちの開発者は既にそれを行う方法を知っています。私たちは長年にわたってテーブルとカラムを持つデータベースを扱ってきました。 、INSERT、UPDATE、DELETE。これは簡単なはずです。
RESTには自己記述性やハイパーメディアの制約など、議論する部分もありますが、これらの制約はリソースの識別や統一されたインターフェースほど単純ではありません。望ましい目標が単純さである複雑さ。
RESTのこのウォーターバージョンは、さまざまな方法で開発者文化で検証されました。リソース識別と統一インターフェースを推奨するサーバーフレームワークが作成されましたが、他の制約をサポートしませんでした。アプローチの差別化について（HI-REST vs LO-REST、Corporate REST vs Academic REST、REST vs RESTful）。
一部の人々は、すべての制約を適用しないとRESTではないことを叫びます。あなたは利益を得られません。半分のRESTはありません。しかし、それらの声は、彼らの貴重な言葉が不明瞭から盗まれて主流になったことに動揺している宗教的な熱狂者として分類されました。 RESTをより難しくすることを試みるJ深い人々。
この用語であるRESTは間違いなく主流になりました。 APIを備えたほぼすべての主要なウェブプロパティは、「REST」をサポートしています。 TwitterとNetflixは2つの非常に注目度の高いものです。怖いのは、自己記述的なパブリックAPIを1つしか考えられず、ハイパーメディア制約を本当に実装している少数のAPIがあることです。確かに、StackOverflowやGowallaのようないくつかのサイトは応答でリンクをサポートしていますが、それらのリンクには大きな隙間があります。 StackOverflow APIにはルートページがありません。 Webサイトのホームページがなければ、Webサイトがどれほど成功したか想像してみてください！
あなたは私が恐れていると誤解されました
これまでのところ、あなたの質問に対する短い答えは、これらのAPI（NetflixとTwitter）がすべての制約に準拠していないため、REST apis持参することになっています。
RESTクライアントは、SOAPクライアントよりも構築に時間がかかりますが、特定の1つのサービスに結び付けられていないため、サービス間でそれらを再利用できる必要があります。ブラウザー。Webブラウザーがアクセスできるサービスの数は？フィードリーダーはどうですか？平均的なTwitterクライアントがアクセスできるサービスの数は？はい、1つだけです。
RESTクライアントは、単一のサービスとインターフェースするように構築されることは想定されていません。それらは、任意のサービスによって提供される可能性のある特定のメディアタイプを処理するために構築されることになっています。それに対する明らかな質問は、どのようにしてapplication/jsonまたはapplication/xmlを配信するサービスのRESTクライアントを構築できますか。できません。それはできません。 a REST client。自分で言った、
実際のスキーマまたは参照ドキュメントがないため、パイプを介して戻るものについて「推測」する必要があります
あなたはTwitterのようなサービスには絶対に正しいです。ただし、RESTの自己記述的な制約は、HTTPコンテンツタイプヘッダーが、ワイヤを介して送信されるコンテンツを正確に記述する必要があることを示しています。application/ jsonおよびapplication/xmlの配信は、コンテンツ。
RESTベースのシステムのパフォーマンスを考慮する場合、エンベロープのバイトについて話すことは、クイックソートとシェルソートを比較するときのループの巻き戻しについて話すことに似ています。 。SOAPのパフォーマンスが向上するシナリオがあり、RESTのパフォーマンスが向上するシナリオがあります。コンテキストがすべてです。
RESTは、サポートするメディアの種類について非常に柔軟であり、キャッシュを高度にサポートすることにより、パフォーマンス上の利点の多くを獲得します。キャッシングがうまく機能するためには、ほぼすべての制約に従う必要があります。
読み取り可能なURLに関する最後のポイントは、最も皮肉なことです。ハイパーメディアの制約に真にコミットすると、すべてのURLはGUIDになり、クライアント開発者は読みやすくなります。
URIがクライアントに対して不透明でなければならないという事実は、RESTシステムを開発する際の最も重要なことの1つです。読み取り可能なURLはサーバー開発者にとって便利であり、適切に構造化されたURLによってサーバーフレームワークが簡単になりますリクエストをディスパッチしますが、これらは実装の詳細であり、APIを使用する開発者に影響を与えません。
Twitter APIはRESTfulに近いものでもないため、SOAPを介してTwitter APIを使用するメリットはありません。 Netflix APIははるかに近いものですが、汎用メディアタイプを使用しているため、1つの制約を順守しないと、サービスから得られるメリットに大きな影響を与える可能性があります。
すべてが彼らのせいではないかもしれません
私はサービスプロバイダーに大量のダンプを行いましたが、RESTfulに踊るには2つかかります。サービスはすべての制約を宗教的に遵守する場合がありますが、クライアントはすべての利点を簡単に取り消すことができます。
クライアントが特定の種類のリソースにアクセスするためにURLをハードコーディングしている場合、サーバーはそれらのURLを変更できません。サービスがそのURLを構造化する方法の暗黙の知識に基づいたあらゆる種類のURL構築は違反です。
リンクから返される表現のタイプを推測すると、問題が発生する可能性があります。 HTTPヘッダーに明示的に記述されていない知識に基づいて表現の内容について仮定を行うと、将来的に痛みを引き起こすカップリングが確実に作成されます。
SOAPを使用する必要がありますか？
個人的にはそうは思いません。 REST done rightにより、分散システムを長期にわたって進化させることができます。異なる人々によって開発され、長年にわたって持続する必要があるコンポーネントを備えた分散システムを構築している場合、RESTはかなり良いオプションです。
SOAPはobject-oriented、remote procedure callテクノロジースタックです。既存のプロトコル（HTTP）の上に新しい抽象化を構築することで機能します。
RESTはdocument指向アプローチであり、既存のプロトコル（HTTP）の機能を単純に使用します。 「REST」は単なる流行語です。概念は次のとおりです。Webをdesignedのように使用するだけです！
質問の編集への応答：
"RESTサービスの実装は、SOAPサービスの実装よりも無限に長くかかります。"
ええ、いや、それは無限に長くすることはできません。また、取得しようとしているのが既にドキュメントまたはファイルである場合、実際にはmはるかに高速です。たとえば、WMS（Web Mapping Service）のOGC仕様では、プロトコルのSOAPおよびRESTバージョンの両方が定義されており、SOAPバージョンを実装している人はほとんどいないという理由があります。マップを取得しようとする場合、URLを構築してそのURLから画像バイトを取得する方が、SOAPメッセージにカプセル化するよりもずっと簡単だからです。しかし、はい、Webサービスの目的がドメインオブジェクトモデルで厳密に型指定されたオブジェクトを転送することである場合、SOAPがその使用により適していることに同意します。
"とにかくXMLを返すRESTサービスを書くのはなぜですか？"
まあ、はい、それは愚かなことができます。しかし、それはXMLが何であるかに依存します。明確に定義されたスキーマがどこかにあれば、あいまいさはありません。たとえば、WSDL URLは、Webサービスに関する情報を取得するための一種のRESTful Webサービスであると考えることができます。この場合、別のSOAP要求のオーバーヘッドを追加しても意味がありません。
一般に、転送されるコンテンツがfile、単一のユニットとして考えられる場合、RESTが勝ちます。 SOAPは、コンテンツをmembersを持つオブジェクトとして扱う必要がある場合に優先されます。
"SOAPにはSOAPエンベロープの「オーバーヘッド」があるという苦情を聞きました。この日と年齢では、本当に心配する必要がありますかほんの一握りのバイト？」
はい。すべての状況においてではありませんが、トラフィックが多いサイトが違いを生みます。 RESTの代わりにSOAPを使用することのsemanticの違いを上回るのに十分な違いはありますか？疑わしい。オブジェクトリモーティングプロトコルを実行していて、バイト数に違いがある場合は、とにかくSOAPはおそらくあなたのためのツールではありません-代わりにCORBAまたはDCOMを使用する必要があります。
"RESTを使用すると、URLをブラウザにポップしてデータを表示できるという議論を聞いたことがあります。"
はい、これはブラウザでデータを表示するのが理にかなっている場合はRESTを支持する大きな議論です。たとえば、画像データを使用すると、サービスを簡単にデバッグできます。URLをブラウザのアドレスバーに貼り付けて、画像がどのように見えるかを確認してください。または、返されるデータがXMLであり、ブラウザーで参照可能なHTMLにレンダリングされる参照XMLスタイルシートがある場合、セマンティックマークアップと簡単な視覚化の利点をすべて1つのパッケージで取得できます。しかし、あなたは正しいです。この利点は、より複雑な認証スキームを操作するときにほとんど失われます。すべての認証情報を各HTTP要求にエンコードできない場合、それはまったくRESTとしてカウントされないことを主張します。
「リソースごとに「読み取り可能な」URLが必要なのはなぜですか？サービスを実装するツールを使用している場合、実際のURLを本当に気にしますか？」
まあ、それは依存します。 Web上のリソースに読み取り可能なURLが必要なのはなぜですか？理論的根拠については、Tim Berners-LeeのエッセイCool URIs Do n't Changeを読むことができますが、基本的には、リソースがまだある限り将来的には、そのリソースのURIは同じままにする必要があります。
明らかに、一時的なリソース（エッセイの「今日のお金」リンクなど）の場合、対応するリソースがなくなるとリソースを参照する必要がなくなるため、その必要はありません。しかし、より永続的なリソース（StackOverflowの質問、IMDBの映画など）の場合、永久に機能するURLが必要です。 Webサービスを設計するときは、リソース自体がサービスよりも長持ちするかどうかを判断する必要があります。その場合、RESTがおそらく正しい方法です。
記録のために、はい、NetFlixやTwitterが存在するかなり前からWebページを開発してきました。いいえ、NetFlixまたはTwitterのサービスのいずれかにクライアントを実装する必要性や機会はまだありません。しかし、サービスの操作がひどく困難であっても、その上にサービスを実装したテクノロジーが悪いことを意味するわけではありません。ただ、これら2つの実装が悪いというだけです。
長い話を短くするには：RESTとSOAPはjust toolsです。それぞれに長所と短所があります。あなたが持っている唯一のツールがハンマーである場合、すべての問題は釘のように見えます。したがって、両方のツールを理解し、それらを正しく使用する方法を学び、各ジョブに適切なツールを選択してください。
Martin Fowlerには Richardson Maturity Modelの投稿 があり、SOAPとRESTの違いを説明するのに非常に役立ちます。
WSDLおよび他のドキュメントレベルのプロトコルは冗長です。 HTTPプロトコルは、ドキュメントの提供とフォームの送信だけでなく、はるかに豊富な操作セットをサポートします。
RESTのサポーターは、その冗長性に不快です。