sockets - 低遅延メッセージング用のREST。

Question

クライアントサーバーシステムにRESTアーキテクチャを使用している人が増えないのはなぜですか。ソケット、TIBCO RV、EMS、MQを使用している人を見かけますが、基本的なRESTアーキテクチャーはあまり見ていません。

高スループット/低遅延のクライアント/サーバー通信にこのアーキテクチャを使用しない理由を誰かが知っていますか

Answer 1

RESTはすべての問題に適しているわけではありません。

RESTはリソース管理に最適です。（クライアントサーバーシステムのように）Webサービスを作成している場合は、言語に依存しないデータ表現、引数の検証、クライアント/サーバーコードの生成、エラー処理、アクセス制御などが必要です。基本的に、RESTではそれらを自分でコーディングする必要があります。

一方、HTTPレイヤーを追加します。プロキシやキャッシュなどをシームレスに統合できますが、HTTPヘッダー、Webサーバーフロントエンドなどが原因で速度が低下します。

Answer 2

必ずしもそれを避けるかどうかはわかりませんが、高スループットで低遅延のサービスにそれを選択しない理由がいくつか考えられます。まず、メッセージをサービスに届けるために Web スタック全体を処理する必要があります。これにより、メッセージを遅延させる不要なレイヤーやサービスが多数導入される可能性があります。カスタム サービスは、サービス自体が必要とするプロトコル層のみをサポートする必要があります。

第 2 に、そのサービスが Web サーバーでホストされている唯一のサービスでない限り、メッセージを処理するための他の要求と競合することになります。サービスのカスタム エンドポイントを使用してもリソース競合の問題がすべて解決されるわけではありませんが、少なくとも他のサービスからエンドポイントへのアクセスを競合する必要はありません。

第 3 に、カスタム プロトコルは、実際のサービス関連のプロトコル情報のみをサポートする必要があり、追加の HTTP プロトコル オーバーヘッドをサポートする必要がないため、パケット サイズが小さくなる可能性があります。これは、小さなメッセージを交換するプロトコルに特に影響を与えます。これは、ヘッダー情報がメッセージ サイズの大部分を占めるためです。