私は現在、検証エラーが発生するたびに401 Unauthorizedを返しています。ジャンゴ/ピストンベースのREST APIアプリケーションです。HTTP ステータス コード レジストリこれが検証失敗の適切なコードであるとは思えません。皆さんは何をお勧めしますか?
- 400不正な要求
- 401 権限がありません
- 403禁止します
- 405 メソッドは許可されていません
- 406 受け入れられません
- 412 前提条件が失敗しました
- 417 期待に応えられなかった
- 422 処理できないエンティティ
- 424 依存関係に失敗しました
更新: 上記の「検証失敗」は、アプリケーション レベルのデータ検証失敗、つまり日時の指定が間違っている、電子メール アドレスが間違っているなどを意味します。
ベストアンサー1
「検証失敗」がリクエストに何らかのクライアント エラーがあることを意味する場合は、HTTP 400 (不正なリクエスト) を使用します。たとえば、URI に ISO-8601 の日付が含まれているはずなのに、形式が間違っているか 2 月 31 日を参照している場合は、HTTP 400 を返します。エンティティ本体に整形式の XML が含まれていると予想していて、解析に失敗した場合も同様です。
(2016年1月): 過去5年間ウェブDAVのより具体的なHTTP 422（処理不可能なエンティティ）は、HTTP 400の非常に合理的な代替手段となっています。例えば、JSON APIただし、HTTP 422はHTTP 1.1には含まれていないことに注意してください。RFC-7231。
リチャードソンとルビーRESTful Web サービスさまざまな HTTP 応答コードをいつ使用するかについての非常に役立つ付録が含まれています。
400 (“不正なリクエスト”)
重要度: 高。
これは一般的なクライアント側のエラー ステータスで、他の 4xx エラー コードが適切でない場合に使用されます。クライアントが PUT または POST リクエストとともに表現を送信し、その表現が正しい形式であるが意味をなさない場合によく使用されます。(p. 381)
そして：
401 (“Unauthorized”)
重要度: 高。
クライアントは、適切な認証資格情報を提供せずに、保護されたリソースを操作しようとしました。間違った資格情報を提供したか、まったく提供しなかった可能性があります。資格情報は、ユーザー名とパスワード、API キー、または認証トークンなど、問題のサービスが期待するものであれば何でもかまいません。クライアントが URI を要求し、どのような資格情報をどのような形式で送信するかを知るために 401 を受け入れることはよくあります。[...]