無効なデータのREST応答コード

以下のシナリオの場合、クライアントにどの応答コードを渡す必要がありますか？

1. 間違ったメール形式のようにユーザー登録中に無効なデータが渡されました
2. ユーザー名/メールアドレスは既に存在します

403を選びました。また、使用できると感じたのもわかりました。

ウィキペディア：

412前提条件が失敗しました：サーバーは、要求者が要求に入力した前提条件の1つを満たしていません

403以外を使用する必要がある場合は、コードを提案してください。

どちらの場合も400が最適です。エラーをさらに明確にしたい場合は、理由フレーズを変更するか、エラーを説明する本文を含めることができます。

412-最終変更日とETagを使用する場合、条件付き要求に前提条件の失敗が使用されます。

403-Forbiddenは、サーバーがリソースへのアクセスを禁止したい場合に使用されます。

他に可能な唯一の選択は、422-処理できないエンティティです。

422をお勧めします。これはメインのHTTP仕様の一部ではありませんが、パブリック標準（WebDAV）で定義されており、他の4xxステータスコードと同じようにブラウザーで処理する必要があります。

RFC 4918から：

422（Unprocessable Entity）ステータスコードは、サーバーがリクエストエンティティのコンテンツタイプを理解しているため（415（Unsupported Media Type）ステータスコードが不適切）、リクエストエンティティの構文が正しい（つまり、400（Bad Request ）ステータスコードは不適切）ですが、含まれている指示を処理できませんでした。たとえば、XMLリクエストの本文に整形式（つまり、構文的には正しい）が含まれているが、意味的に誤りのあるXML命令が含まれている場合に、このエラー条件が発生する可能性があります。

リクエストを正しく解析できなかった場合（リクエストエンティティ/ボディを含む）、適切な応答は400 Bad Request [ 1 ]です。

RFC 4918は、要求エンティティが構文的には整形式であるが意味的には誤りである場合、422 Unprocessable Entityが適用可能であると述べています。したがって、リクエストエンティティが文字化けしている場合（不適切なメール形式のように）、400を使用します。（のように@example.com）意味をなさない場合は、422を使用してください。

質問に記載されているように、ユーザー名/メールが既に存在するという問題の場合は、409の競合 [ 2 ]を使用して、競合の説明とその解決方法に関するヒント（この場合は「別のユーザー名/メール」）。ただし、記述されている仕様では、この場合は403 Forbidden [ 3 ]も使用できますが、HTTP承認に関する引数はあります。

412 Precondition Failed [ 4 ]は、クライアントから提供された前提条件要求ヘッダー（などIf-Match）がfalseと評価された場合に使用されます。つまり、クライアントは何かを要求して前提条件を提供し、それらの前提条件が失敗する可能性があることを十分に理解しています。412は、クライアントに突然発生することはありません。また、リクエストエンティティ自体に関連付けられるべきではありません。

418 I'm a teapotCSRFチェックの失敗やリクエストプロパティの欠落など、明らかに細工された悪意のある「発生する可能性のない」リクエストに戻るのは面白いです。

2.3.2 418私はティーポットです

ティーポットでコーヒーを入れようとすると、エラーコード「418 I'm a teapot」が表示されます。結果のエンティティボディは短くて頑丈な場合があります。

それをかなり深刻に保つために、面白いエラーコードの使用を、ユーザーに直接公開されていないRESTfulエンドポイントに制限します。