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

Question

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

高スループット/低スループットのクライアント/サーバー通信では、レイテンシー

Answer 1

私は必ずしも避けたいとは思っていませんが、高いスループット、低い遅延のサービスのために私がそれを選んでいないかもしれない理由。まず、あなたのサービスにあなたのメッセージを届けるために、Webスタック全体を扱わなければなりません。これにより、メッセージを遅延させる不要なレイヤーやサービスが多数導入される可能性があります。カスタムサービスは、サービス自体が必要とするプロトコルレイヤーのみをサポートする必要があります。あなたのサービスは、Webサーバー上でホストされている唯一のサービスでなければ

第二に、あなたはあなたのメッセージのために他のリクエストと競合することがありますがサービスされます。サービスのカスタムエンドポイントを持つと、すべてのリソース競合問題が解決されるわけではありませんが、少なくとも、他のサービスからエンドポイントへのアクセスを競合する必要はありません。

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

Answer 2

RESTは、すべての問題に適していないです。

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

一方、HTTPレイヤーを追加します。プロキシやキャッシュなどのシームレスな統合が得られますが、HTTPヘッダー、Webサーバーのフロントエンドなどのためにスピードが落ちます。