432

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

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

更新: 上記の「検証の失敗」は、アプリケーション レベルのデータ検証の失敗、つまり、日時の指定の誤り、偽の電子メール アドレスなどを意味します。

4

9 に答える 9

328

「検証の失敗」がリクエストに何らかのクライアント エラーがあることを意味する場合は、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 (「Bad Request」)
重要度: 高。
これは一般的なクライアント側のエラー ステータスであり、他の 4xx エラー コードが適切でない場合に使用されます。クライアントが PUT または POST 要求と共に表現を送信し、表現が正しい形式である場合によく使用されますが、意味がありません。(p.381)

と：

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

于 2009-12-25T04:13:13.433 に答える
109

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 命令が含まれている場合に発生する可能性があります。

于 2014-08-25T15:43:18.997 に答える
35

データベース内の重複は409 CONFLICT.

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

ここで 4xx コードについて詳しく説明します: http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

于 2014-10-16T23:06:37.990 に答える
24

ここにあります：

rfc2616#section-10.4.1 - 400 不正な要求

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

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 が誤って使用される

于 2015-12-04T12:53:13.763 に答える
9

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

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

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

于 2009-12-24T22:47:24.050 に答える
1

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

個人的には、おそらく を使用400 Bad Requestしますが、これは事実の裏付けのない私の個人的な意見です。

于 2009-12-24T22:38:40.207 に答える
0

「検証の失敗」とは正確にはどういう意味ですか? 何を検証していますか？構文エラー (不正な XML など) のようなものを参照していますか?

だとすれば、400 Bad Request がおそらく正しいと思いますが、何を「検証」しているのかを知らなければ、何とも言えません。

于 2009-12-24T22:38:43.317 に答える