REST はステートレスであるため、受信した各リクエストは、受信した前のリクエストを認識していません。この状況で接続プーリングは可能ですか?
接続プールが実装されている場合、標準のデータベース接続と同様に、要求ごとに接続プールを開き、閉じます。
接続プールを利用するために REST をどのように実装できますか?
REST はステートレスであるため、受信した各リクエストは、受信した前のリクエストを認識していません。この状況で接続プーリングは可能ですか?
接続プールが実装されている場合、標準のデータベース接続と同様に、要求ごとに接続プールを開き、閉じます。
接続プールを利用するために REST をどのように実装できますか?
接続プーリング (オブジェクト プール)、キャッシング、および違いとは何かを理解する必要があります。
接続プールは、これらの高価なリソースを作成する費用を回避するために作成されます。それらはほとんど作成されてどこかに保存され、使用された後、プールに戻って再び使用できます。これにより、これらのリソースを何度も作成する費用を回避できました。データベース接続など。
REST の場合、REST サービスへのリクエストはどのように行いますか? PUT、GET、POSTなどを介してHTTP経由で言うことができるので、HTTP接続が必要です。サーバーが気になる場合は、使用しているサーバーによっては、スレッドを使用するものがほとんどです。
キャッシングやオブジェクト プーリングと混同されているのではないかと思います。オブジェクト プールでは、スレッド プールと同じように、X 個のオブジェクトを作成し、プール (通常はキュー) に格納します。必要なときはいつでも、プールから 1 つを求めます。使い終わったら、プールに戻します。
接続プール コンテキストでの REST は理にかなっています。
あなたが望むのはキャッシングです... RESTはステートレスですが、各オブジェクトには一意の識別子があるため、そのIDに基づいてキャッシュできます。
それは確かに可能です。RESTは、サーバーが内部でどのように構築されているかについては何も指示しませんが、状態を無視し、統一された HTTP インターフェースを使用します。したがって、データベースへの接続に接続プールを使用するサーバー プロセスを作成できますが、それでも、REST 全体、ステートレス、ドロップイン コンポーネント スタイルの設計と完全に一致しています。
REST 実装のステートレス性では、リクエストを処理するために必要なすべてのステートが含まれている必要があります。いずれにせよ、サーバーが効率のために状態を維持することを妨げるものではありません。
接続プールは問題ありません。サーバー上の認証キャッシュも問題ありません。うまくいかないのは、次のようなリクエスト フローがある SQL タイプの接続プールです。REST 実装では、{ ログイン + 操作 1 } { ドロップ cnx } { ログイン + 操作 2 } で安全に分割できるため、{ ログイン + 操作 1 / ログイン + 操作 2 } のようなものが必要になるため、サーバーが状態を維持する必要はありません。
REST フレームワークのパフォーマンス チューニングについては、Performance of RESTful appsを読んで、素晴らしいケース スタディとしてProfiling Django REST Frameworkをお勧めします。
ps .: 質問は REST の接続プーリングに焦点を当てていますが、OP の目標は REST サービスのスループット/速度を向上させることであることを示唆しています。