[解決済み] NetflixやTwitterのようなWebサービスにはRESTとSOAPのどちらを使うべきか？[クローズド］

どのように解決するのですか？

炭鉱のカナリア。

私はこのような質問を1年近くも待っていました。この日が来るのは必然であり、これから数ヶ月間、このような質問を多く目にすることになると思います。

警告のサイン

SOAPクライアントよりもRESTfulクライアントを構築する方が時間がかかるのは、まったくそのとおりです。SOAP ツールキットは、多くの定型的なコードを取り除き、ほとんど労力をかけずにクライアント プロキシ オブジェクトを利用できるようにします。Visual Studio のようなツールとサーバー URL を使用すると、任意の複雑なリモート オブジェクトに 5 分以内にローカルでアクセスできます。

application/xml や application/json を返すサービスは、クライアント開発者にとって非常に厄介です。そのデータの塊をどうしろというのでしょうか。

幸いなことに、RESTサービスを提供する多くのサイトは、クライアントライブラリの束も提供しており、それらのライブラリを使用して、強く型付けされたオブジェクトの束にアクセスすることができます。しかし、ちょっと間抜けな感じもします。もし彼らが SOAP を使用していたなら、私たち自身でそれらのプロキシクラスをコード生成することができたでしょう。

SOAPのオーバーヘッド、ハ。殺すのはレイテンシーです。もし人々がワイヤーを通過する余分なバイトの数を本当に心配しているなら、HTTPは正しい選択ではないかもしれません。ユーザーエージェントヘッダーがどれだけのバイトを使用しているか見たことがありますか？

ええ、HTML と javascript 以外のデバッグ ツールとして Web ブラウザーを使用してみたことがありますか。信じてください、それは最悪です。動詞は 2 つしか使えないし、キャッシュは常に邪魔だし、エラー処理は多くの情報を飲み込むし、favicon.ico を常に探し続けるし、最悪です。もう、いい加減にしてくれ。

読みやすいURL。名詞だけで、動詞は使わない。CRUD操作だけを行い、オブジェクトの階層に1つの方法でアクセスする必要がある限り、それは簡単なことです。残念ながら、ほとんどのアプリケーションはそれよりも少し多くの機能を必要とします。

差し迫った災難

現在、REST サービスと統合するアプリケーションを開発している膨大な数の開発者が、あなたと同じ結論に達している最中です。彼らは、シンプルさ、柔軟性、スケーラビリティ、進化性、およびセレンディピティ再利用の聖杯を約束されていました。Web 自体の特性として、物事はうまくいかないものなのです。

しかし、バージョン管理も同様に問題ですが、コンパイラーは問題の検出を助けてくれないことが分かってきました。データ構造が進化し、URLがリファクタリングされると、手書きのクライアント コードは保守するのが面倒になります。名詞と 4 つの動詞だけで API を設計することは、特に RESTful Url の狂信者がクエリ文字列をいつ使用できて、いつ使用できないかを教えてくれるので、本当に難しいことなのです。

開発者は、なぜ私たちはJsonフォーマットとXmlフォーマットの両方をサポートすることに無駄な労力を使っているのか、なぜ1つに労力を集中し、それをうまくやらないのか、と尋ね始めるでしょう。

なぜこんなにうまくいかないのでしょうか。

何がいけなかったのかをお話ししましょう。私たち開発者は、マーケティング部門に私たちの主な弱点を利用されました。私たちは銀の弾丸を永遠に探し続け、REST が本当は何であるかという現実に目をつぶっていました。表面上、RESTはとても簡単でシンプルに見えます。リソースにUrlで名前を付け、GET、PUT、POST、DELETEを使用するのです。私たち開発者は、テーブルやカラム、SELECT、INSERT、UPDATE、DELETEといったSQLステートメントを持つデータベースを何年も扱ってきているので、そのやり方はすでに知っているのです。それは簡単なことだったはずです。

RESTの他の部分として、自己記述性、ハイパーメディア制約などが議論されていますが、これらの制約は、リソース識別や統一インターフェースほど単純なものではありません。望まれるゴールがシンプルであるところ、複雑さを追加しているように見えます。

この水増しされたバージョンのRESTは、多くの方法で開発者文化の中で検証されるようになりました。サーバー フレームワークが作成され、リソースの識別と統一されたインターフェイスが推奨されましたが、他の制約をサポートすることは何もありませんでした。HI-REST vs LO-REST、Corporate REST vs Academic REST、REST vs RESTful など、アプローチを区別する用語が出回るようになりました。

もしあなたがすべての制約を適用しないなら、それはRESTではないと叫ぶ人が何人かいました。利点を得ることはできません。半端なRESTは存在しないのです。しかし、それらの声は、自分たちの貴重な用語が無名から盗まれて主流になったことに怒った宗教的狂信者というレッテルを貼られました。RESTを実際よりも難しく聞こえるようにしようとする嫉妬深い人たちです。

REST という用語は、間違いなく主流になりました。API を持つほとんどすべての主要な Web プロパティは、REST をサポートしています。Twitter と Netflix は、非常に有名な 2 つの例です。恐ろしいことに、自己記述可能な公開APIは1つしかなく、ハイパーメディア制約を本当に実装しているものはほんの一握りしかありません。確かにStackOverflowやGowallaのようないくつかのサイトは回答でリンクをサポートしているが、そのリンクには大きな穴がある。StackOverflow APIにはルートページがありません。もし Web サイトのホームページがなかったら、Web サイトがどれだけ成功していたか想像してみてください!

あなたは誤解していたようです。

もしあなたがここまで来たのなら、あなたの質問への短い答えは、これらのAPI（NetflixとTwitter）はすべての制約に準拠していないため、REST APIがもたらすはずの利点を得ることはできない、ということです。

RESTクライアントはSOAPクライアントより構築するのに時間がかかりますが、1つの特定のサービスに縛られないので、サービス間で再利用することができるはずです。古典的な例として、Web ブラウザーを見てみましょう。ウェブブラウザはいくつのサービスにアクセスできるでしょうか？フィード・リーダーならどうでしょう？では、平均的なTwitterクライアントは、いくつの異なるサービスにアクセスできるでしょうか？そう、たった一つです。

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 つの制約にさえ従わないと、サービスから得られる利点に重大な影響を与える可能性があることを示しています。

すべてが彼らの責任ではないかもしれません

私はサービスプロバイダのことを散々非難してきましたが、RESTfullyに踊るには2つ必要です。サービスは宗教的にすべての制約に従うかもしれませんが、クライアントはまだ簡単にすべての利点を元に戻すことができます。

クライアントが特定のタイプのリソースにアクセスするために URL をハードコードすると、サーバーがそれらの URL を変更するのを妨げてしまいます。サービスがどのように URL を構造化するかについての暗黙の知識に基づく、いかなる種類の URL の構築も違反です。

リンクからどのような種類の表現が返されるかについて仮定することは、問題を引き起こす可能性があります。HTTP ヘッダーに明示されていない知識に基づいて表現のコンテンツについて仮定することは、間違いなく将来的に苦痛をもたらす結合を生み出すことになるでしょう。

彼らは SOAP を使用すべきでしたか?

個人的には、そうは思いません。正しく行われたRESTは、分散システムを長期にわたって進化させることができます。もしあなたが、異なる人々によって開発されたコンポーネントを持ち、何年も続く必要がある分散システムを構築しているなら、RESTはかなり良い選択肢です。