炭鉱のカナリア。
私はこのような質問を1年近く待っています。この日が来るのは必然であり、今後数か月以内にこのような質問がさらに増えると思います。
警告サイン
あなたは完全に正しいです。RESTfulクライアントの構築にはSOAPクライアントよりも時間がかかります。SOAPツールキットは、多くのボイラープレートコードを取り除き、ほとんど手間をかけずにクライアントプロキシオブジェクトを使用可能にします。Visual StudioのようなツールとサーバーのURLを使用すると、任意の複雑さのリモートオブジェクトにローカルで5分未満でアクセスできます。
application / xmlおよびapplication / jsonを返すサービスは、クライアント開発者にとって非常に煩わしいものです。そのデータの塊で何をすることになっているのでしょうか？
幸いなことに、RESTサービスを提供する多くのサイトは一連のクライアントライブラリも提供しているため、これらのライブラリを使用して、強く型付けされた一連のオブジェクトにアクセスできます。ちょっと馬鹿げているようです。彼らがSOAPを使用していた場合は、これらのプロキシクラスを自分でコード生成できます。
SOAPオーバーヘッド、ヘクタール。レイテンシーは殺します。人々がネットワークを行き来する余分なバイトの数を本当に心配しているなら、おそらくHTTPは正しい選択ではありません。ユーザーエージェントヘッダーで使用されるバイト数を確認しましたか？
ええ、HTMLとJavaScript以外のデバッグツールとしてWebブラウザを使用したことはありますか。信じられない。動詞は2つしか使用できません。キャッシングは常に邪魔になり、エラー処理は非常に多くの情報を飲み込んでしまいます。ちょうど私を撃ちます。
読み取り可能なURL。名詞のみ、動詞なし。ええ、CRUD操作のみを実行していて、オブジェクトの階層に1つの方法でアクセスするだけでよい限り、これは簡単です。残念ながら、ほとんどのアプリケーションにはそれよりも少し多くの機能が必要です。
差し迫った災害
RESTサービスと統合するアプリケーションを現在開発している開発者のメトリックボートロードは、あなたが持っているものと同じ一連の結論に至る過程にあります。それらは、シンプルさ、柔軟性、スケーラビリティ、進化性、そして偶発的な再利用の聖杯を約束されていました。ウェブ自体の特性、物事がうまくいかない場合があります。
ただし、バージョニングも同様に問題であることがわかっていますが、コンパイラは問題の検出に役立ちません。手書きのクライアントコードは、データ構造が進化し、URLがリファクタリングされるときに維持するのが面倒です。名詞と4つの動詞のみを中心としたAPIの設計は、特にクエリ文字列を使用できる場合と使用できない場合にRESTful Url zealotsが通知する場合は、非常に難しい場合があります。
開発者はなぜJson形式とXml形式の両方のサポートに私たちの努力を無駄にしているのか、なぜ私たちの努力を1つに集中してうまくやらないのかと尋ね始めます。
どうしてそんなにうまくいかなかったの
何が悪かったのかをお話しします。開発者としての私たちは、マーケティング部門に私たちの主な弱点を利用させました。銀の弾丸に対する私たちの永遠の探求は、RESTが何であるかの現実に私たちを盲目にしました。一見すると、RESTはとても簡単でシンプルに見えます。リソースにURLで名前を付け、GET、PUT、POST、DELETEを使用します。地獄、私たちの開発者はすでにその方法を知っています。私たちは何年もの間、テーブルと列、およびSELECT、INSERT、UPDATE、DELETEを持つSQLステートメントを持つデータベースを扱ってきました。それは簡単なはずだった。
RESTには、自己記述性やハイパーメディア制約など、RESTの他の部分について説明する部分もありますが、これらの制約は、リソースの識別や統一されたインターフェースほど単純ではありません。望ましい目標が単純さである場合は、複雑さが増すようです。
RESTのこの衰退したバージョンは、多くの方法で開発者の文化で検証されました。リソースの識別と統一されたインターフェースを奨励するサーバーフレームワークが作成されましたが、他の制約をサポートするものは何もありませんでした。用語は、アプローチの差別化に浮かび始めました（HI-REST対LO-REST、企業REST対学術REST、REST対RESTful）。
一部の人は、すべての制約を適用しないとRESTではないことを叫びます。メリットはありません。RESTの半分はありません。しかし、それらの声は彼らの貴重な言葉が不明瞭から盗まれて主流になったことに腹を立てた宗教的な狂信者として分類されました。RESTのサウンドを実際よりも難しくしようとする嫉妬深い人々。
RESTという用語は、間違いなく主流になりました。APIを持つほとんどすべての主要なWebプロパティが「REST」をサポートしています。TwitterとNetflixは2つの非常に注目度の高いものです。怖いのは、自己記述的なパブリックAPIは1つしか考えられず、ハイパーメディアの制約を実際に実装している少数のAPIがあるということです。StackOverflowやGowallaなどの一部のサイトは、応答でリンクをサポートしていますが、リンクには大きなギャップホールがあります。StackOverflow APIにはルートページがありません。Webサイトのホームページがない場合、Webサイトがどれほど成功したかを想像してみてください。
あなたは私が恐れている誤解を招きました
ここまで進んだ場合、質問に対する簡単な答えは、それらのAPI（NetflixおよびTwitter）がすべての制約に準拠していないため、REST APIがもたらすはずの利点を得られないということです。
RESTクライアントは、SOAPクライアントよりもビルドに時間がかかりますが、特定の1つのサービスに関連付けられていないため、サービス間で再利用できるはずです。Webブラウザーの古典的な例を見てみましょう。Webブラウザーはいくつのサービスにアクセスできますか？フィードリーダーについてはどうですか？平均的なTwitterクライアントがアクセスできるサービスはいくつありますか？はい、1つだけです。
RESTクライアントは、単一のサービスとインターフェースするように構築されているわけではなく、任意のサービスによって提供される特定のメディアタイプを処理するように構築されているはずです。それに対する明白な質問は、application / jsonまたはapplication / xmlを提供するサービス用のRESTクライアントをどのように構築できるかです。まあできません。これは、これらの形式がRESTクライアントにとって完全に役に立たないためです。自分で言った
実際のスキーマや参照ドキュメントがないため、パイプを介して何が返されるかについて「推測」する必要があります
あなたはTwitterのようなサービスに完全に正解です。ただし、RESTの自己記述的制約では、HTTPコンテンツタイプヘッダーは、ネットワーク経由で送信されるコンテンツを正確に記述する必要があると述べています。application / jsonおよびapplication / xmlを配信しても、コンテンツについては何もわかりません。
RESTベースのシステムのパフォーマンスを検討する場合は、全体像を確認する必要があります。エンベロープバイトについて話すことは、クイックソートとシェルソートを比較するときのループの巻き戻しについて話すようなものです。SOAPのパフォーマンスが向上するシナリオとRESTのパフォーマンスが向上するシナリオがあります。コンテキストがすべてです。
RESTは、サポートするメディアタイプについて非常に柔軟であり、キャッシングに対する高度なサポートを提供することで、パフォーマンス上の利点の多くを獲得します。キャッシングがうまく機能するためには、ほぼすべての制約に従う必要があります。
可読URLに関する最後のポイントは、最も皮肉なことです。ハイパーメディアの制約に真にコミットすると、すべてのURLがGUIDになる可能性があり、クライアント開発者は読みやすさを失うことはありません。
URIがクライアントに対して不透明でなければならないという事実は、RESTシステムを開発するときに最も重要なことの1つです。読み取り可能なURLはサーバー開発者にとって便利であり、適切に構造化されたURLはサーバーフレームワークがリクエストをディスパッチするのを容易にしますが、これらはAPIを使用する開発者に影響を与えない実装の詳細です。
Twitter APIはRESTfulであることすら近づいていないため、SOAPを介して使用することの利点を見ることができません。Netflix APIははるかに近いですが、一般的なメディアタイプを使用しているため、1つの制約さえ守らないと、サービスから得られるメリットに大きな影響を与える可能性があります。
彼らのせいではないかもしれません
私はサービスプロバイダーで大量のダンプを行いましたが、RESTfulに踊るには2つ必要です。サービスはすべての制約に忠実に従う可能性があり、クライアントは依然としてすべての利点を簡単に取り消すことができます。
クライアントが特定のタイプのリソースにアクセスするためにURLをハードコーディングすると、サーバーがそれらのURLを変更できなくなります。サービスがURLをどのように構造化するかについての暗黙の知識に基づくあらゆる種類のURL構築は違反です。
リンクから返される表現のタイプについて想定すると、問題が発生する可能性があります。HTTPヘッダーに明示的に記述されていない知識に基づいて表現の内容を想定すると、将来的に問題を引き起こすカップリングが確実に作成されます。
彼らはSOAPを使用するべきでしたか？
個人的にはそうは思いません。RESTが正しく行われることにより、分散システムを長期にわたって進化させることができます。さまざまな人が開発したコンポーネントがあり、何年も続く必要がある分散システムを構築している場合、RESTは非常に良いオプションです。