別のAPIで一般的なクライアントの懸念を抽象化することは意味があります

Question

最近、私はHTTP ReSTクライアント、メッセージングクライアント、データベースクライアントなど、さまざまなクライアント側APIで作業しました。 （この

• 接続プーリング
• 非同期にし、バックオフポリシーの実装と
• 要求の再試行を扱うクリーンなエラーでI/Oを非ブロック： は、いずれの場合も、同じ問題が、次のされている、跳びRESTとメッセージングのためのより多くのケース）
• リクエストのバッチ処理（これはデータベースのためのより多くのケースである）

私はそれを見る方法で、上記の懸念がトンから抽出することができます彼は独立したAPIで基本的な要求をしています。さらに、上記の問題をコード化する複雑さのために、コストを複数回支払わないのが理にかなっている。

したがって、すべての要求を非同期に実行しながら、すべての種類の要求を再試行してバッチ処理する汎用クライアントヘルパーAPIが必要になります。 これはタスクエグゼキュータAPIのようなものですが、実行する必要のあるタスクが1つしかないため、スケジューリングなど他の複雑さはありません。

私の質問ですか、何か不足していますか？

Answer 1

私はそれらを別々にしておきたいと思います。私の推測では、これらのそれぞれについてサードパーティーのソリューションを見つけることができますが、私は3つすべてを行うライブラリについてはわかりません。

あなたのJavaプログラミングについてはわかりませんが、apacheプロジェクトはcommons- *ライブラリでユーティリティをセグメント化するのに良い仕事をしてくれたと思います。そこからインスピレーションを得ることができます。

https://commons.apache.org/