検証が失敗した場合にREST AP Iサービスによって返される適切なHTTPステータスコードは何ですか？
Django / Piston based REST APIアプリケーションで検証エラーが発生した場合は常に401 Unauthorizedを返しています。を見てきた HTTP Status Code Registry これがバリデーションの失敗にふさわしいコードだとは思わない、何をお勧めしますか？
- 400不正な要求
- 401未承認
- 403禁止します
- 405許可されていないメソッド
- 406不可
- 412前提条件が失敗しました
- 417期待失敗
- 422処理不能なエンティティ
- 424失敗した依存関係
更新：上記の「検証失敗」とは、アプリケーションレベルでのデータ検証失敗、つまり誤った日時、偽の電子メールアドレスなどを意味します。
「検証失敗」が要求に何らかのクライアントエラーがあることを意味する場合は、HTTP 400（Bad Request）を使用してください。たとえば、URIの日付がISO-8601であることが想定されていて、その形式が間違っているか2月31日を参照していることが判明した場合は、HTTP 400を返します。解析に失敗します。
（1/2016）：過去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）です） ）ステータスコードは不適切ですが、含まれている命令を処理できませんでした。例えば、このエラー状態は、ＸＭＬ要求本体が整形式（すなわち、構文的には正しい）だが意味的に誤りのあるＸＭＬ命令を含む場合に発生する可能性がある。
データベース内の重複は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（処理不能なエンティティ）ステータスコードは、サーバーを意味します
リクエストエンティティのコンテンツタイプを理解し（したがって415（サポートされていないメディアタイプ）ステータスコードは不適切です）、リクエストエンティティの構文は正しい（したがって400（Bad Request）ステータスコードは不適切です）が、含まれている命令を処理できませんでした。たとえば、XML要求本文に整形式（つまり、構文的に正しい）であるが意味的に誤った、XML命令が含まれている場合、このエラー状態が発生する可能性があります。
結論
経験則：[_] 00は、最も一般的なケースと、指定されたコードでカバーされないケースをカバーします。
422 は最適なオブジェクト検証エラーに適合します（正確に私の推奨事項:)
意味論的に誤り-「このユーザー名は既に存在します」検証のようなものを考えてください。
400はオブジェクト検証に誤って使用されます
私は技術的にはHTTPの失敗ではないかもしれません、リソースが（おそらく）正しく指定され、ユーザーが認証され、操作上の失敗がなかったからです（ただし、仕様には402 Payment Requiredのような予約コードも含まれます）厳密にはHTTPに関連していますが、どのデバイスでも状態を認識できるように、プロトコルレベルでそれを保持することをお勧めします。
それが実際にそうであるならば、私は以下のようにアプリケーションエラーでレスポンスにステータスフィールドを追加するでしょう。
<status><code> 4</code> <message>日付範囲が無効です</message> </status>
これらのエラーのセマンティクスについてのもう少し詳しい情報が RFC 2616 にあります。これはHTTP 1.1を文書化したものです。
個人的には、おそらく400 Bad Requestを使用しますが、これは私の個人的な意見であり、事実上のサポートはありません。
「検証失敗」とはどういう意味ですか。何を検証していますか？あなたは構文エラーのようなもの（例えば、不正なXML）を参照していますか？
その場合は、400 Bad Requestがおそらく正しいことだと思いますが、それが「検証」であるかどうかを知らずに言うのは不可能です。