格納されたクレジットカードを使用した注文など、ユーザーとの多くの対話を処理するRESTful APIを作成しています。
注文が成功した場合、200 OKを返します。注文リクエストの形式が正しくないか無効な場合、400 Bad Requestを返します。しかし、注文の実際の処理中に問題が発生した場合、何を返すべきですか?
最後のステップは問題です-他の理由で注文が完了しない場合、何を返しますか?考えられるシナリオは次のとおりです。
これは、400または500のどちらにも適しているとは思えません。より良いコードがなければ、400と見なすことができます。ビジネスルールに従って、リクエストは無効でした。正確に見えません。
編集:また、同じトピックの この既存のディスカッション が見つかりました。そこにあるすべての答えは、このタイプの違反にステータスコードを使用することを指しているようです。
クライアントがリクエストを修正してエラーを回避できる場合は、クライアントエラーに4xxを使用する必要があります。クライアントが実際に回避できないサーバーエラーには5xxを使用します。
製品が完売した場合、サーバーエラーになります。クライアントは、エラーを回避するために何らかの方法でリクエストを変更することはできません。別の製品に切り替えることはできますが、それは新しいリクエストではありませんか?
ユーザーの最大注文数に達した場合もサーバーエラーです。そのエラーを回避するためにクライアントができることは何もありません。
クレジットカード取引の失敗は、クライアントエラーになります。クライアントは、エラーを回避するために、異なる支払い方法またはクレジットカード番号でリクエストを再送信できます。
エラーの種類:
4×× Client Error
エラーコード:
422 Unprocessable Entity
サーバーは、リクエストエンティティのコンテンツタイプを理解し(したがって、415 Unsupported Media Typeステータスコードは不適切)、リクエストエンティティの構文は正しい(したがって、400 Bad Requestステータスコードは不適切)が、含まれているものを処理できませんでした指示。
たとえば、XML要求本文に整形式(つまり、構文的に正しい)であるが、意味的に誤ったXML命令が含まれている場合、このエラー状態が発生する可能性があります。
この質問は古いことは知っていますが、今日もまったく同じ質問を思いつきました。ユーザーがクレジットを使い果たした場合、REST APIが返すステータスコードは何ですか?
私は402 Payment Required
:
Wikipedia :によると
将来の使用のために予約されています。元々の意図は、このコードが何らかの形式のデジタル現金またはマイクロペイメントスキームの一部として使用される可能性があることでしたが、それは実現されておらず、このコードは通常使用されません。特定の開発者がリクエストの1日の制限を超えた場合、Google Developers APIはこのステータスを使用します。
そして確かに 彼らはする :
PAYMENT_REQUIRED(402)
- 開発者が設定した1日の予算制限に達しました。
- 要求された操作には、クォータが許可するより多くのリソースが必要です。操作を完了するには支払いが必要です。
- 要求された操作には、認証されたユーザーからの何らかの支払いが必要です。
424 Failed Dependency
?仕様では次のように説明されています。
要求されたアクションは別のアクションに依存しており、そのアクションは失敗したため、リソースでメソッドを実行できませんでした。
しかし、 この定義 もあります:
ステータスコード424はWebDAV標準で定義されており、クライアントが実行していることをクライアントが変更する必要がある場合に使用します。ここではサーバーで問題は発生していません。
注文を作成し、残高を差し引くことになっている内部アクションがあり、それらのアクションの1つが完全に正当な理由で失敗したこと、そしてそれがリクエストが失敗した理由であることをクライアント(またはふり)に伝えることができます。
私が見る限り、「アクション」は非常に広い用語であり、在庫不足、クレジット不足、倉庫パーティーの夜など、さまざまな状況で使用できます。
別のオプションは 422 Unprocessable Entity
:
サーバーはリクエストエンティティのコンテンツタイプを理解し(したがって、415 Unsupported Media Typeステータスコードは不適切です)、リクエストエンティティの構文は正しい(したがって、400 Bad Requestステータスコードは不適切です)が、含まれているものを処理できませんでした指示。
たとえば、XML要求本文に整形式(つまり、構文的に正しい)であるが、意味的に誤ったXML命令が含まれている場合、このエラー状態が発生する可能性があります。
在庫切れのアイテムをリクエストしようとしたり、クレジットが不足している場合は、セマンティックレベルの間違いと見なされる可能性があります。
おそらく在庫不足または倉庫パーティーの夜は一時的な状態と見なされる可能性があるため、後でリクエストを再試行できます。その状況は 503 Service Unavailable
サーバーは現在、一時的な過負荷または定期的なメンテナンスが原因でリクエストを処理できません。これは、しばらくしてから緩和される可能性があります。
サーバーは、Retry-Afterヘッダーフィールドを送信して、クライアントが要求を再試行する前に待機する適切な時間を提案する場合があります。
400はすべてのビジネスシナリオに使用できるとは思いません。基本的なデータ入力検証に使用できます。それ以外に、他のビジネスロジックをこのエラーコードに時間を合わせるのは難しいかもしれません。これによって処理されるエラーのほとんどは、開発者がクライアントのコーディング中に発生する可能性のある設計時エラーです。
すべてのパラメーターが正しいとし、ユーザーアカウント番号をリクエストに渡しているとしましょう。
そのため、リクエストはもはや悪いリクエストではなく、サーバーはリクエストを受け入れることができます。しかし、現在では、利用可能な新しい情報に基づいてリクエストを完了することを拒否しています。つまり、アカウントに十分な残高がありません。
これらのシナリオでは、403を適切なエラーメッセージとともに使用することをお勧めします。
その他の考えられるエラーコードは、409の競合です。しかし、それはリソースが一貫した状態にあるシナリオで使用されます。
私は406 Not Acceptable
。
4xxリストは次のとおりです。
const HTTP_BAD_REQUEST = 400;
const HTTP_UNAUTHORIZED = 401;
const HTTP_PAYMENT_REQUIRED = 402;
const HTTP_FORBIDDEN = 403;
const HTTP_NOT_FOUND = 404;
const HTTP_METHOD_NOT_ALLOWED = 405;
const HTTP_NOT_ACCEPTABLE = 406;
const HTTP_PROXY_AUTHENTICATION_REQUIRED = 407;
const HTTP_REQUEST_TIMEOUT = 408;
const HTTP_CONFLICT = 409;
const HTTP_GONE = 410;
const HTTP_LENGTH_REQUIRED = 411;
const HTTP_PRECONDITION_FAILED = 412;
const HTTP_REQUEST_ENTITY_TOO_LARGE = 413;
const HTTP_REQUEST_URI_TOO_LONG = 414;
const HTTP_UNSUPPORTED_MEDIA_TYPE = 415;
const HTTP_REQUESTED_RANGE_NOT_SATISFIABLE = 416;
const HTTP_EXPECTATION_FAILED = 417;
const HTTP_I_AM_A_TEAPOT = 418; // RFC2324
const HTTP_MISDIRECTED_REQUEST = 421; // RFC7540
const HTTP_UNPROCESSABLE_ENTITY = 422; // RFC4918
const HTTP_LOCKED = 423; // RFC4918
const HTTP_FAILED_DEPENDENCY = 424; // RFC4918
const HTTP_RESERVED_FOR_WEBDAV_ADVANCED_COLLECTIONS_EXPIRED_PROPOSAL = 425; // RFC2817
const HTTP_UPGRADE_REQUIRED = 426; // RFC2817
const HTTP_PRECONDITION_REQUIRED = 428; // RFC6585
const HTTP_TOO_MANY_REQUESTS = 429; // RFC6585