私は 412 (Precondition Failed) を考えていますが、より良い基準があるのでしょうか?
9 に答える
ステータス 422 は、仕様に基づいて最も適切なようです。
422 (Unprocessable Entity) ステータス コードは、サーバーがリクエスト エンティティのコンテンツ タイプを理解していることを意味し (したがって、415 (Unsupported Media Type) ステータス コードは不適切です)、リクエスト エンティティの構文は正しい (したがって 400 (Bad Request) ) ステータス コードが不適切です) が、含まれている命令を処理できませんでした。たとえば、このエラー状態は、XML 要求本文に整形式 (つまり、構文的に正しい) が含まれているが、意味的に誤った XML 命令が含まれている場合に発生する可能性があります。
彼らは、不正な形式の xml が不適切な構文 (400 を呼び出す) の例であると述べています。不正な形式のクエリ文字列はこれに類似しているように見えるため、400 は、パラメーターが欠落している整形式のクエリ文字列には適切ではないようです。
UPDATE @DavidV は、この仕様がコア HTTP ではなく WebDAV 向けであることを正しく指摘しています。しかし、一般的な WebDAV 以外の API の中には、より適切なステータス コードがないために 422 を使用しているものもあります (これを参照してください)。
設定された標準があるかどうかはわかりませんが、最新の HTTP 仕様 (2014 年以降)で次のように文書化されている400 Bad Requestを使用していたでしょう。
6.5.1. 400不正な要求
400 (Bad Request) ステータス コードは、クライアント エラーと見なされる何かが原因で、サーバーがリクエストを処理できない、または処理しないことを示します (例: 不正なリクエスト構文、無効なリクエスト メッセージ フレーミング、不正なリクエスト ルーティング)。
.NETのWCF APIは、 webHttpBindingHTTP 404
を使用するときに、「エンドポイントが見つかりません」というエラーを返すことによって不足しているパラメーターを処理します。
404 Not Found
Web サービスのメソッド名とそのパラメーター シグネチャを考慮すると、これは理にかなっています。つまり、Web サービス メソッドを公開してLoginUser(string, string)
をリクエストLoginUser(string)
した場合、後者は見つかりません。
基本的に、これは、呼び出している Web サービス メソッドと、指定したパラメーター シグネチャが見つからないことを意味します。
10.4.5 404が見つかりません
サーバーは Request-URI に一致するものを見つけられませんでした。状態が一時的なものか永続的なものかは示されていません。
は400 Bad Request
、Gert が提案したように、有効な応答コードのままですが、通常は下位レベルの問題を示すために使用されると思います。これは、不正な HTTP 要求、欠落または無効な HTTP ヘッダーなどとして簡単に解釈される可能性があります。
10.4.1 400 不正な要求
構文が正しくないため、サーバーは要求を理解できませんでした。クライアントは、変更なしでリクエストを繰り返すべきではありません。
400 Bad Request コードを送信できます。これは、より汎用的な 4xx ステータス コードの 1 つであるため、意図した意味で使用できます。クライアントは、アプリケーションが正しく処理するために必要な情報/パラメーターが欠落しているリクエストを送信しています。
必要なパラメーターの何かが API エンドポイントが必要とするものと一致しない場合 (パスワードが短すぎるなど)、通常は 422 (処理できないエンティティ) を選択しますが、パラメーターが欠落している場合は 406 (受け入れられません) を選択します。
興味のある人にとっては、Spring MVC(少なくとも3.x)はこの場合400を返しますが、これは私には間違っているようです。
いくつかのGoogleURL(accounts.google.com)をテストし、必要なパラメーターを削除しました。この場合、通常は404が返されます。
Googleをコピーします。
404 Not Found
指定されたリソースが見つからないため、 a を使用する必要があると主張できます。
私はよく 403 Forbidden エラーを使用します。理由は、要求が理解されたということですが、要求されたとおりにするつもりはありません (物事が間違っているため)。応答エンティティは何が問題なのかを説明するため、応答が HTML ページの場合、エラー メッセージはページ内にあります。JSON または XML 応答の場合、エラー情報はそこにあります。
rfc2616から:
10.4.4 403 禁止
サーバーは要求を理解しましたが、要求を満たすことを拒否しています。
承認は役に立たず、要求を繰り返すべきではありません。
リクエスト メソッドが HEAD ではなく、サーバーがリクエストが実行されなかった理由を公開したい
場合、拒否の理由をエンティティに記述する必要があります。サーバーがこの情報をクライアントに提供したくない場合は、代わりにステータス コード 404
(Not Found) を使用できます。