REST APIでステートフル情報を維持する
REST Spring Bootを使用してJSONを受け入れるAPIを開発しています。認証にSpring Securityを使用しています。2つのサービスを使用するユースケースがあり、1つはサードパーティシステムへの接続をテストし、サードパーティシステムからデータを取得するもう1つの方法。
- api/system/connection
- api/system/customData
最初のサービスを呼び出すときに、サードパーティシステムに正常に接続できるかどうかを確認します。はいの場合、「成功」または「失敗」のメッセージを返します。 customDataを取得するために2回目の呼び出しを行おうとすると、リクエストにはサードパーティシステムへのログイン情報が含まれているはずです。もう一度新しい接続を作成し、カスタムデータをフェッチしてデータを返します。このアプローチの問題は、接続オブジェクトを毎回作成することです。これにより、各リクエストで多くの時間が消費されます。
このオーバーヘッドを回避するには、2番目のリクエストを次のように変更する必要があります
api/system/connection /？/ customData
しかし、これを行うには、接続をテストする最初のサービスで何を返す必要がありますか？
- 接続自体を返す必要がありますか？接続オブジェクトをJSONに変換し、2番目のリクエストでそれをデシリアライズすることは可能ですか？それも安全なことですか？
- この接続をサーバー側のサードパーティシステムにキャッシュし、各接続に一意のIDを返す必要がありますか？しかし、これはAPIのRESTfulな性質を壊しませんか？
それとも、この問題への取り組み方に別のアプローチがありますか？.
TIA。
この特定のケースでは、@ Ewanが通知したとおり、最初のリクエストはまったく必要ないと思います。
しかし、そのようなニーズがある場合は、いくつかのセッショントークンを使用して状態を渡すことができます（OAuth Bearer authentication token。リクエスト間のいくつかの状態情報を保持できます。
ただし、よく考えてください。 REST APIは、状態管理なしの方が優れています。
わかりました、私の経験から。 ApacheHttpClientを使用して、APIへのリクエストを実行します。 APIのヘルスチェックは、早期に知りたい場合に適しています。たとえば、いくつかのバッチ操作を実行します-APIに対して数百または数千の呼び出しを行います。しかし、ほとんどの場合、APIからのHTTP応答コード、接続タイムアウト、問題のあるケースを処理するための例外があります。そのため、通常は2つの呼び出しを行って接続が正常であることを確認し、必要な呼び出しを行います。接続の作成について-ApacheHttpClient 4.0ライブラリを確認してください。そこに接続マネージャーがあります。多くの呼び出しを行う必要がある場合は、スレッド化が役立つ場合があります。応答を取得するのに250〜400ミリ秒かかる場合、基本的に同じ時間で50の応答を取得するために50の並列呼び出しがある可能性があります。