保存されたクレジットカードを使用して注文を行うなど、さまざまなユーザー操作を処理する RESTful API を作成しています。
注文が成功した場合は 200 OK を返し、注文リクエストが不正な形式または無効な場合は 400 Bad Request を返します。しかし、注文の実際の処理中に問題が発生した場合には、何を返すべきでしょうか?
- クライアントは、ユーザー リソースの注文をサーバーに POST します。ユーザーが存在しない場合は、404 Not Found が返されます。
- 注文の形式と情報が検証されます。有効でない場合は、400 Bad Request が返されます。
- 注文が処理されます。注文が成功した場合、注文に対して 201 Created が返されます。予期しないエラーが発生した場合、500 Server Error が返されます。
最後のステップが問題です。他の理由で注文が完了しなかった場合、何を返品すればよいのでしょうか? 考えられるシナリオは次のとおりです。
- 商品は売り切れです
- ユーザーの最大注文制限に達しました
- クレジットカード取引失敗（残高不足など）
これは 400 にも 500 にも適切ではないようです。 より良いコードがない場合は、400 として見ることができます。つまり、ビジネス ルールに従ってリクエストが無効だったということです。 正確ではないようです。
編集: また発見この既存の議論同じトピックの。そこでの回答はすべて、このタイプの違反に対してステータス コードを使用することを指しているようで、400、409、または 422 拡張の使用について議論されています。
ベストアンサー1
ビジネス ルールには 4xx を使用する必要があります。注文が受け入れられなかった場合は 2xx を返さないでください。HTTP はアプリケーション プロトコルです。そのことを忘れないでください。2xx を返すと、本文で送信した情報に関係なく、クライアントは注文が受け入れられたと想定できます。
From [RESTful Web Services Cookbook][1]:
One common mistake that some web services make is to return a status code that reflects success (status codes from 200 to 206 and from 300 to 307) but include a message body that describes an error condition. Doing this prevents HTTP-aware software from detecting errors. For example, a cache will store it as successful response and serve it to subsequent clients even when clients may be able to make a successful request.