REST：一時的な例外を特定する方法は？

Question

RESTfulエンドポイントまたは一般的に任意のHTTPエンドポイントを呼び出すときに障害が発生する可能性に対処しようとしているので、HTTP仕様または業界に標準またはパターンがあるかどうかを判断し、例外は一時的なものであり、特に再試行の目的ではない場合。

リモートサービスはいつでも失敗する可能性があるため、操作を再試行するタイミングを決定することは、分散アーキテクチャの基本的な機能である必要があります。

最初にメソッドべき等性を検討することから始めました（つまり、get、put、deleteは、サービス契約に従って再試行しても安全です）。
次に、ステータスコードを検討しました。 4xxは再試行されませんが、5xxエラーは、エラーのタイプ、つまり一時的かどうかに応じて再試行される場合があります。たとえば、リモートサービスがデータベースを使用していて、クエリタイムアウトが原因で5xxエラーが発生した場合は、状態が一時的であるため再試行しても安全であり、再試行するとサービスの呼び出しが成功する可能性が高くなります。ただし、一時的ではなく、再試行を避けたい他のタイプのエラーが存在する可能性があります。たとえば、以前は、DBAがテーブルに新しい制約を追加し、それから機能していたサービスが制約違反などの非一時的なエラーで失敗し始めたことにより、エラーが発生していました。

以前は、500のエラーを無限に再試行するというミスを犯しました。それらは常に一時的であり、リモートサービスは最終的に回復してリクエストを処理できると考えていました。特に、コンピューター間の相互作用（オーケストレーション）では、複雑な補償トランザクションと部分的に処理された要求をDLQに発行して後で人間が介入する必要があるため、例外の伝播を避けたいところです。

一般に、業界の人々が通常この問題にどのように対処するか、この「一時性」の特性がHTTPプロトコルを使用してサーバーからクライアントにどのように伝えられるかを知りたいです。

カスタマイズされたhttpステータスコードを使用する必要がありますか、それともこのプロパティをヘッダーまたは本文のプロパティで通知する必要がありますか？

これのための標準化された解決策がある場合？

もしあれば、サードパーティのサービスが正しく動作することを認識してサービスを消費することを期待でき、同時に、特定の実装のために再試行プロトコルを再構成する必要なしにサービスを消費することもできるので、それは素晴らしいことです。

私は、将来的にサードパーティのサービスと統合する必要がある可能性のあるエコシステムの良質なサービス市民を構築するのに役立つ優れたサービス契約を設計するための再試行プロトコルに関する提案を歓迎します。

これまでのところ、このような分散アーキテクチャパターンでは再試行可能性がファーストクラスの市民にならないことに特に驚いていますが、実装がどのように機能するかについての解釈が間違っている可能性があります。誰かが私を正しい方向に向けることができますか？

Eric Stein · Accepted Answer

一時的なエラーの場合は、500を返さないでください。戻り値 503 Service Unavailable 。クエリのタイムアウトは、コードの根本的なエラーではなく、「一時的な過負荷」が原因です。応答に、クライアントが要求を再試行するまで待機する時間を示す Retry-After ヘッダーを含めます。

FrustratedWithFormsDesigner · Answer

無限に再試行することは、おそらく良い考えではありません。何かがダウンしてすぐに起動しない場合、それはリソースの浪費です。私がこの状況をどのように処理したかは、再試行の数が固定されていて、再試行の間の遅延がますます長くなっていたことです。私の経験では、何回か再試行しても応答がない場合は、おそらく数時間ダウンします。しかし、それはただmyの経験です...

再試行の頻度と各再試行を待機する頻度の詳細は、操作している特定のサービスに依存する可能性があり、そのサービスの経験に依存する必要があるだけです。

アプリケーションが通信する1つのサービスが時々タイムアウトになるが、通常、再試行は成功する。 5xxエラーコードが返されたことはありません（タイムアウトのログに504が表示されますが、それ以外のログは表示されません）。これまでのところ、私は5回以上再試行する必要はなく、各再試行の間に少なくとも30秒待機していました。彼らのサーバーは遅いことが知られており、以前は過負荷になっています。（別のベンダーの）別のサービスは常に非常に迅速に応答しますが、5xxコード（通常は500または503）を返す場合があり、通常は1回または2回の再試行でその問題が解決されます。何かが許容される再試行の量を超える場合、重大なエラーとしてログに記録され、アプリケーションは他の処理を続けます。

もう1つ：サービスとクライアントを両方と記述している場合は、5xxエラーの応答メッセージにさらに詳細な情報を追加できます。そうすることで、作成中のサービスが一部のエラーからは回復できるが、他のエラーからは回復できないことがわかっている場合は、その詳細を応答に含めて、クライアントが再試行するかどうかを知ることができます。例として、レート制限があるサービスを1つ見ました。この制限を超えると、5xxエラー応答には、制限がリセットされてから再試行できるようになるまでの分数である「retry-after」ヘッダーが付属しています。したがって、その場合、カスタムヘッダー（他のユーザーのために文書化する必要がある）には、特定の再試行シナリオに関する情報が含まれています。