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

Question

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

高スループット/低レイテンシのクライアント/サーバー通信にこのアーキテクチャを使用することを避ける理由を誰かが知っていますか

Answer 1

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

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

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

Answer 2

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

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

一方、HTTPレイヤーを追加します。プロキシ、キャッシュなどのシームレスな統合を取得しますが、HTTPヘッダー、ウェブサーバーフロントエンドなどのために速度をいくらか失います。