自動再試行をトリガーしてはならないHTTPエラーはどれですか。
私はいくつかのマイクロサービスをより回復力のあるものにしようと試みており、特定のタイプのHTTPリクエストを再試行することはそれを助けるでしょう。
タイムアウトを再試行すると、クライアントの動作が著しく遅くなるため、この場合は再試行するつもりはありません。不正なリクエストは数ミリ秒後も不正なリクエストのままであるため、400を再試行しても効果はありません。
他のいくつかのタイプのエラーを再試行しない理由は他にもあると思いますが、どのエラーが発生し、その理由は何ですか？
永続的なように見えるため、再試行すべきではないエラーがいくつかあります。
- 400不正な要求
- 401無許可
- 402支払いが必要
- 403禁止します
- 405メソッドは許可されていません
- 406受け入れ不可
- 407プロキシ認証が必要です
- 409競合-状況によって異なります
- 410なくなった
- 411必要な長さ
- 412前提条件が失敗しました
- 413ペイロードが大きすぎます
- 414 URIが長すぎます
- 415サポートされていないメディアタイプ
- 416範囲が満足できません
- 417予想に失敗しました
- 418私はティーポットです-これはわかりません
- 421誤ったリクエスト
- 422処理できないエンティティ
- 423ロック-平均してリソースがロックされている時間によって異なります（？）
- 424失敗した依存関係
- 426アップグレードが必要-クライアントを自動的にアップグレードできますか？
- 428前提条件が必要-プロセス全体の最初からやり直さなくても、前提条件を2度満たすことはできませんが、状況によって異なります
- 429リクエストが多すぎます-依存しますが、高速に再試行しないでください
- 431リクエストヘッダーフィールドTooLarge
- 451法的な理由で利用不可
したがって、4 **クライアントエラーのほとんどは再試行すべきではありません。
再試行してはならない5 **サーバーエラー：
- 500内部サーバーエラー
- 501実装されていません
- 502不正なゲートウェイ-一時的なエラーに使用されるので、依存しているようです
- 505 HTTPバージョンはサポートされていません
- 506バリアントも交渉
- 507ストレージ不足
- 508ループが検出されました
- 510拡張されていません
- 511ネットワーク認証が必要です
ただし、マイクロサービスの回復力を高めるには、 サーキットブレーカー パターンを使用し、アップストリームがダウンしているときにすばやく失敗するようにします。
4xxコードは、呼び出し側でエラーが発生したことを意味します。不正なURL、不正な認証資格情報、または不正なリクエストであることを示す何かが考えられます。したがって、その問題を修正せずに、再試行を使用することはできません。エラーは呼び出し元のドメインにあり、呼び出し元はそれ自体が修正されることを期待する代わりに修正する必要があります。
例外があります。サービスが再デプロイまたは再起動されているとしましょう。そのインスタンスでは、エンドポイントが登録されていないため、4xx httpコードを送信します。ただし、しばらくすると、サーバーが使用可能になる場合があります。したがって、再試行は有益に思えるかもしれません。
より深い分析は、サービスが再起動されたとき、停止を防ぐためにローリング再起動であることを示します。したがって、前の議論はもはや成り立たない。ただし、環境/エコシステムがこの慣例に従っていない場合、クライアント側から報告されたエラー（4xxコード）が前述の理由により再試行する価値があると思われる場合は、再試行することを選択できます。しかし、成熟したシステムでは、メリットが認識されず、フェイルファスト機能が失われるため、これは行われません。
5xxエラーコードはサービスエラーであるため、再試行する必要があります。短期的（スレッドのオーバーフロー、依存サービスによる接続拒否）または長期的（システム障害、依存システムの停止、インフラストラクチャの利用不可）の可能性があります。これが永続的であるか一時的であるかに関係なく、サービスは情報（多くの場合ヘッダー）で応答します。時には再試行する時間に関する時間パラメータ。これらのパラメーターに基づいて、呼び出し元は再試行するかどうかを選択できます。
1xx、2xx、および3xxコードは、明白な理由で再試行する必要はありません。