問題タブ [idempotent]

特定の読み取り専用ディレクトリからすべてのファイルを読み取って処理するために、ポーリング コンシューマー パターンを使用しています。べき等性を無視するオプションはありますか?

noop=true & idempotent=false で定義されたルートがシステム全体をクラッシュさせる (無限ループ) ことは理解していますが、プーリング コンシューマー パターンは特定の瞬間にトリガーされる 1 回限りの操作です。

これは GET メソッドに関する一般的な質問です。

ユーザーが最後に選択したページネーション サイズを保存する必要があるとします。

製品のリストを閲覧することはもちろん GET リクエストであり、ページング サイズを変更することも GET リクエストです (sizeパラメーターのみを変更します)。

ユーザーがサイズを変更するたびに、新しいサイズをバックエンドに保存する必要があります。

GET が状態を変更してはならないという事実に対処する方法は? クエリを発行する（したがって、アプリケーションの状態を変更する）料金は、私にとって非常に間違っています。代替手段はありますか？

GET 指定されたリソースの表現を要求します。GET を使用したリクエストは、データを取得するだけで、他の効果はありません。

私が見た多くの記事と商用 API から、ほとんどの人は、クライアントに requestId またはべき等キー (例: https://www.masteringmodernpayments.com/blog/idempotent-stripe-requests )を提供するように依頼することで、API をべき等にしています。基本的に requestId <-> レスポンス マップをストレージに格納します。したがって、このマップに既に含まれているリクエストが着信した場合、アプリケーションは保存されたレスポンスを返すだけです。

これは私にとってはすべて良いことですが、私の問題は、最初の通話がまだ進行中のときに 2 番目の通話が着信した場合をどのように処理するかということです。

だからここに私の質問があります

1. 理想的な動作は、最初の呼び出しが終了して最初の呼び出しの応答を返すまで、2 番目の呼び出しを待機することでしょうか? これが人々のやり方ですか？

2. はいの場合、最初の呼び出しが終了するまで 2 番目の呼び出しはどのくらい待機する必要がありますか?

3. 2 番目の呼び出しに待機時間制限があり、最初の呼び出しがまだ終了していない場合、クライアントに何を伝えるべきでしょうか? クライアントがタイムアウトして再試行するように、応答を返さないようにする必要がありますか?

RESTful アーキテクチャでは、POST リクエストはSafeでもIdempotentでもありません。

error現在、jQuery の ajax 呼び出しは、関数を使用して失敗をキャッチするように ajax 呼び出しを設定することで、失敗した要求を再試行し、オプションで呼び出しを再試行することができます (関連するtimeout、tryCount、retryAfterなどの設定と共にretryLimit)。

GET 呼び出しを再試行することは問題ではありませんが (どちらも安全で冪等であるため)、POST 呼び出しを再試行するにはどうすればよいでしょうか?

たとえば、ajax POST を使用して新しいレコードを挿入するとします。

1. クライアントで ajax POST 呼び出しが開始されます。
2. 呼び出しはサーバーによって受信され、データベースが更新されます。
3. サーバーは応答しますが、この応答はクライアントに配信されません。
4. そのため、クライアントは失敗があったと想定し、呼び出しを再試行します。
5. 呼び出しはサーバーによって再度受信され、別の変更が行われます。
6. 等々...

このシナリオに対応する最善の方法は何でしょうか?

HyperLogLog [ HLL ] を使用して、ドメイン サービスの冪等性へのアプローチを評価しています。

このアプローチの目的は、大量の役に立たない情報を保存することなく、冪等性を保証する一般的な方法を提供することです。時折の重複に対する許容度のみが必要です (1 通ではなく 2 通のメールを送信してください)。

私のシナリオでは、すべてのサービス リクエストは toHashCode 関数を持つメッセージ オブジェクトです。アルゴリズムは次のようになります。

1. リクエストを受信すると、ドメイン サービスは HLL[ S1 ] カーディナリティを計算し、それをC1として保存します。
   
2. リクエストハッシュ [ H ] がHLL [ S2 ] のコピーに追加され、カーディナリティがC2として格納されます。
   
3. C1 == C2の場合、リクエストは複製され、S2は破棄されます。
4. それ以外の場合、リクエストは処理され、ハッシュ [ H ] が HLL [ S1 ] に追加されます。

誰かが同様の解決策に遭遇しましたか? （ブルームフィルターのような）
この種のソリューションの欠点は何ですか？