[解決済み] 一般的なリクエストに失敗した場合（エラーではない）、適切なHTTPステータスコードのレスポンスは何でしょうか？

質問

私は、保存されたクレジットカードを使用して注文することを含む、多くのユーザーインタラクションを処理するRESTful APIを作成しています。

注文が成功した場合、私は 200 OK を返し、注文要求が不正であるか無効である場合、私は 400 Bad Request を返しています。しかし、実際の注文処理中に問題が発生した場合は、何を返せばよいのでしょうか。

1. クライアントがサーバーにユーザー リソースの注文を POSS します。ユーザーが存在しない場合、404 Not Found が返されます。
2. 注文の形式と情報が検証されます。有効でない場合、400 Bad Request が返されます。
3. 注文が処理されます。注文が成功した場合、その注文に対して201 Createdが返されます。予期しないエラーが発生した場合、500 Server Errorが返されます。

最後のステップが問題です。他の理由で注文が完了しなかった場合、何を返せばよいのでしょうか。考えられるシナリオは次のとおりです。

• 製品が完売している
• ユーザーによる注文の上限に達しました
• クレジットカード決済の失敗（残高不足など）

これは 400 にも 500 にも適さないように思えます。どちらかというと、よりよいコードがない場合は 400 と見なされるかもしれません - 要求はビジネス ルールによると無効でした。ただ、正確ではないようです。

編集: さらに この既存の議論 を見つけました。そこでのすべての回答は、このタイプの違反にステータスコードを使用することを指摘しているようで、400、409、または422拡張を使用するかどうかについて議論されています。

どのように解決するのですか?

ビジネスルールには400を使用する必要があります。注文が受理されなかった場合、2xx を返してはいけません。HTTP はアプリケーション プロトコルであり、そのことを決して忘れてはなりません。もしあなたが2xxを返した場合、クライアントは、あなたがボディで送ったどんな情報にも関係なく、注文が受け入れられたと仮定することができます。

いくつかのウェブサービスが犯すよくある間違いは、成功を反映したステータスコード（200から206までのステータスコード）を返すことです。 コードを返すことです (ステータスコードは 200 から 206、300 から 307 まで)。 307)を返しますが、エラー状態を説明するメッセージボディを含んでいます。 これは、HTTP を認識するソフトウェアがエラーを検出するのを妨げます。例えば 例えば、キャッシュが成功したレスポンスとして保存し、後続のクライアントに提供します。 キャッシュは成功レスポンスとして保存し、後続のクライアントに提供します。 リクエストを成功させることができる場合でも、キャッシュは成功レスポンスとして保存し、後続のクライアントに提供します。

4xxと5xxの判断はお任せしますが、エラーステータスコードを使用した方が良いでしょう。