検証エラーに対してREST APIサービスによって返される適切なHTTPステータスコードは何ですか？

Django / PistonベースのREST APIアプリケーションで検証エラーが発生するたびに、現在401 Unauthorizedを返しています。見ていたたHTTPステータスコードレジストリ Iをy'allのは何をお勧めします、これは検証の失敗のために適切なコードであることを確信していませんよ？

• 400不正な要求
• 401無許可
• 403禁止します
• 405メソッドは許可されていません
• 406受け入れ不可
• 412前提条件が失敗しました
• 417予想に失敗しました
• 422処理できないエンティティ
• 424失敗した依存関係

更新：上記の「検証エラー」とは、アプリケーションレベルのデータ検証エラーを意味します。つまり、誤って指定された日時、偽のメールアドレスなどです。

「検証失敗」がリクエストにクライアントエラーがあることを意味する場合、HTTP 400（Bad Request）を使用します。たとえば、URIにISO-8601の日付が含まれていると想定され、その形式が間違っているか、2月31日を参照している場合、HTTP 400が返されます。エンティティ本体で整形式のXMLを想定している場合、解析に失敗します。

（2016年1月）：過去5年間で、WebDAVのより具体的なHTTP 422（Unprocessable Entity）は、HTTP 400の非常に合理的な代替手段になりました。たとえば、JSON APIでの使用を参照してください。ただし、HTTP 422ではHTTP 1.1、RFC-7231には対応していません。

RichardsonとRubyのRESTful Webサービスには、さまざまなHTTP応答コードをいつ使用するかに関する非常に役立つ付録が含まれています。彼らが言う：

400（「悪い要求」）
重要度：高。
これは一般的なクライアント側のエラーステータスであり、他に適切な4xxエラーコードがない場合に使用されます。これは、クライアントがPUTまたはPOSTリクエストとともに表現を送信するときに一般的に使用され、表現は正しい形式ですが、意味がありません。（p.381）

そして：

401（「無許可」）
重要度：高。
クライアントは、適切な認証資格情報を提供せずに保護されたリソースを操作しようとしました。誤った資格情報を提供したか、まったく提供しなかった可能性があります。資格情報は、ユーザー名とパスワード、APIキー、または認証トークンなど、問題のサービスが予期しているものであれば何でもかまいません。クライアントがURIを要求して401を受け入れるのはよくあることです。これにより、送信する資格情報の種類と形式を認識します。[...]

RFC 4918から（およびhttp://www.iana.org/assignments/http-status-codes/http-status-codes.xhtmlにも文書化されています）：

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

データベース内の複製は409 CONFLICTです。

422 UNPROCESSABLE ENTITY検証エラーに使用することをお勧めします。

ここで4xxコードのより長い説明をします：http : //parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

ここにあります：

rfc2616＃section-10.4.1-400 Bad Request

不正な構文のため、サーバーはリクエストを理解できませんでした。クライアントは変更せずにリクエストを繰り返すべきではありません。

rfc7231＃section-6.5.1-6.5.1。400不正な要求

400（Bad Request）ステータスコードは、クライアントエラーと見なされるもの（たとえば、不正なリクエスト構文、無効なリクエストメッセージフレーミング、または不正なリクエストルーティング）が原因で、サーバーがリクエストを処理できない、または処理しないことを示します。

不正な（整形式ではない）ケースを指します！

rfc4918-11.2。422処理できないエンティティ

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

結論

経験則：[_] 00は、最も一般的なケースと、指定されたコードでカバーされないケースをカバーします。

422のフィット最高のオブジェクトの検証エラー（正確には私の推薦:)
については、意味的に誤ったは-検証「このユーザ名はすでに存在している」のようなものと考えてください。

オブジェクトの検証に400が誤って使用されています

リソースは（おそらく）有効に指定されており、ユーザーは認証されており、操作上の失敗はなかったため、技術的にはHTTPの失敗ではない可能性があります（ただし、仕様にさえ、402 Payment Requiredなどの予約済みコードが含まれているため、厳密に言えばHTTP関連ですが、どのデバイスでも状態を認識できるように、プロトコルレベルで設定することをお勧めします。

それが実際の場合、次のようなアプリケーションエラーのある応答にステータスフィールドを追加します。

<status> <code> 4 </ code> <message>日付範囲が無効です</ message> </ status>

HTTP 1.1を文書化しているRFC 2616には、これらのエラーのセマンティクスについてもう少し詳しい情報があります。

個人的にはおそらくを使用します400 Bad Requestが、これは私の個人的な意見であり、事実に基づくサポートはありません。

「検証失敗」とはどういう意味ですか？何を検証していますか？構文エラーのようなもの（たとえば、不正なXML）を参照していますか？

そうであれば、400 Bad Requestはおそらく正しいことだと思いますが、それが何であるかを知らずに「検証」していると言うことは不可能です。