RESTful アーキテクチャを選択する理由の 1 つは、(とりわけ) 負荷の高い Web アプリケーションのスケーラビリティが優れていることだといつも読んでいます。
何故ですか？私が考えることができる理由の 1 つは、すべてのクライアントで同じリソースが定義されているため、キャッシングが容易になることです。最初のリクエストの後、後続のリクエストは memcached インスタンスから提供されます。これも水平方向に適切にスケーリングされます。
しかし、アクションが URL にエンコードされる従来のアプローチ (booking.php/userid=123&travelid=456&foobar=789) でこれを達成することもできませんでした。
RESTの一部は確かにURL部分です（RESTではRです）が、Sはスケーリングにとってより重要です：状態。
RESTのサーバー側はステートレスです。つまり、サーバーはリクエスト間で何も保存する必要がありません。これは、サーバー間に（多くの）通信が必要ないことを意味し、水平方向にスケーラブルになります。
もちろん、R（代表）には小さなボーナスがあります。適切なURLがあれば、ロードバランサーがリクエストを適切なサーバーに簡単にルーティングでき、POSTがマスターに送信される間にGETがスレーブに送信される可能性があります。
トムが言ったことは非常に正確だと思いますが、スケーラビリティに関するもう 1 つの問題は、スケーリングの際の変更に対する障壁です。そのため、REST が意図したとおりの最大のテナントの 1 つは、HyperMedia です。基本的に、サーバーはパスを所有し、実行時にそれらをクライアントに渡します。これにより、既存のクライアントを壊さずにコードを変更できます。ただし、REST のほとんどの実装は、REST の装いの背後に隠れている単純な RPC であることがわかります...これはスケーラブルではありません。
「スケーラブル」または「Web スケール」は、Web、クラウド、および REST に関して最も乱用されている用語の 1 つであり、主に経営陣を説得して、開発チームを REST トレインに乗せるためのサポートを得るために使用されます。
何の価値もない流行語です。Web で「REST スケーラビリティ」を検索すると、多くの人が具体的な証拠なしに互いにオウム返しをしていることがわかります。
REST サービスは、SOAP インターフェースを介して公開されるサービスとまったく同じようにスケーラブルです。どちらも、アプリケーション サービスへの単なる HTTP インターフェイスです。このサービスが実際にどの程度拡張されるかは、このサービスが実際にどのように実装されたかに完全に依存します。REST と SOAP の両方ですべてを拡張できないサービスを作成することは可能です。
はい、SOAP を使用すると、状態やセッションに依存するなど、スケーリングを悪化させることができます。すぐに使用できる SOAP はこれを行いません。これには、よりスマートなロード バランサーを使用する必要があります。これは、スケーリングの形式に本当に関心がある場合に必要です。
SOAP では許可されず、REST で許可されていることの 1 つは、HTTP キャッシング プロキシまたはクライアント側でキャッシュ可能な応答をキャッシュすることです。これにより、多くの操作の応答がキャッシュ可能である場合、REST サービスの負荷が SOAP サービスよりも多少軽くなる可能性があります。これが意味することは、サービスで最終的にリクエストが少なくなるということです。
理由 (おそらく理由ではない)は、RESTful サービスがセッションレスであることです。これは、ロード バランサーを使用して、すべての Web サーバー間でセッション状態を複製したり、単一のセッションからのすべての要求が同じ Web サーバーに送信されるようにしたりすることなく、さまざまな Web サーバーに要求を送信できることを意味します。