無効なデータに対するREST応答コード
以下のシナリオでは、どのレスポンスコードをクライアントに渡すべきですか？
- ユーザー登録中に無効なデータが渡されたため、間違ったEメールフォーマットが発生しました
- ユーザー名/ Eメールアドレスは既に存在します
私は403を選びました。私はまた、私が使うことができると感じることを次のように思いました。
ウィキペディア：
412 Precondition Failed：サーバーは、リクエスターが要求に付けた前提条件の1つを満たしていません
403以外を使用する必要がある場合はコードを提案してください。
どちらの場合も400が最適です。エラーをさらに明確にしたい場合は、理由句を変更するか、エラーを説明するための本文を含めることができます。
412 - 最終更新日とETagを使用する場合、前提条件失敗が条件付き要求に使用されます。
403 - サーバーがリソースへのアクセスを禁止したい場合は、禁止を使用します。
可能な他の唯一の選択肢は422 - Unprocessable entityです。
422をお勧めします。これは主要なHTTP仕様の一部ではありませんが、公開標準（WebDAV）で定義されており、他の4xxステータスコードと同じようにブラウザで扱われるべきです。
422（Unprocessable Entity）ステータスコードは、サーバーが要求エンティティのコンテンツタイプを理解しているため（415（Unsupported Media Type）ステータスコードは不適切です）、要求エンティティの構文は正しい（したがって400（Bad Request）です） ）ステータスコードは不適切ですが、含まれている命令を処理できませんでした。例えば、このエラー状態は、ＸＭＬ要求本体が整形式（すなわち、構文的には正しい）だが意味的に誤りのあるＸＭＬ命令を含む場合に発生する可能性がある。
要求が正しく解析されなかった場合（要求エンティティ/本体を含む）、適切な応答は400 Bad Request[ 1 ]。
RFC 4918 は422 Unprocessable Entityが要求実体が構文的に整形式であるが意味論的に誤りである場合に適用可能であると述べています。そのため、リクエストエンティティが文字化けしている場合（悪いEメールフォーマットなど）、400を使用してください。しかし@example.comのようにそれが意味を成さない場合は422を使用してください。
問題が、質問に記載されているように、ユーザー名/電子メールが既に存在しているということであれば、を使用できます。409 Conflict[ 2 =]競合の説明、およびそれを修正する方法についてのヒント（この場合は「別のユーザー名/電子メールを選択」）。ただし、この仕様では、403 Forbidden[]も使用できますが、HTTP認証に関する引数は無視されます。 。
412前提条件の失敗[ 4 ]は、前提条件要求ヘッダー（例：If-Match）がの場合に使用されます。クライアントから提供されたはfalseと評価されます。つまり、クライアントは何かを要求して前提条件を提供し、それらの前提条件が失敗する可能性があることを十分に認識しています。 412はクライアントの外から出てはいけませんし、リクエストエンティティそれ自体に関連してはいけません。
CSRFチェックの失敗や要求プロパティの欠落など、明らかに巧妙に作成された、または悪意のある、「実行できない」要求に 418 I'm a teapot を返すのは面白いことです。
2.3.2 418私はティーポットです
ティーポットでコーヒーを淹れようとすると、エラーコード「418 I'm a teapot」が表示されます。結果として得られるエンティティ本体は短くて頑丈です。
それを合理的に深刻なものにしておくために、私は面白いエラーコードの使用を直接ユーザーに公開されていないRESTfulエンドポイントに制限します。