412(Precondition Failed)と思っていますが、もっと良い基準があるのでしょうか。
ステータス422は spec に基づいて最も適切と思われます。
422(Unprocessable Entity)ステータスコードは、サーバーが要求エンティティのコンテンツタイプを理解しているため(415(Unsupported Media Type)ステータスコードは不適切です)、要求エンティティの構文は正しい(したがって400(Bad Request)です) )ステータスコードは不適切ですが、含まれている命令を処理できませんでした。例えば、このエラー状態は、XML要求本体が整形式(すなわち、構文的には正しい)だが意味的に誤りのあるXML命令を含む場合に発生する可能性がある。
彼らは、不正な形式のxmlは悪い構文の例であると述べています(400を要求しています)。不正な形式のクエリ文字列はこれに類似しているように思われるため、400は、パラメータが欠落している整形式のクエリ文字列には適していません。
UPDATE@DavidVは、この仕様はWebDAV用であり、コアHTTP用ではないことを正しく指摘しています。しかし、いくつかの人気のある非WebDAV APIは、とにかく、より良いステータスコードがないために422を使用しています( こちらを参照 )。
標準があるかどうかはわかりませんが、400 Bad Request
を使用したはずです。
不正な構文のため、要求をサーバーで理解できませんでした。クライアントは変更なしにリクエストを繰り返すべきではありません(SHOULD NOT)。
.NETの WCF API は、 webHttpBinding を使用しているときに、HTTP 404
"Endpoint Not Found"エラーを返すことによって、不足しているパラメータを処理します。
404 Not Found
は、あなたのWebサービスのメソッド名とそのパラメータのシグネチャを一緒に考えれば意味があります。つまり、WebサービスメソッドLoginUser(string, string)
を公開し、LoginUser(string)
をリクエストした場合、後者は見つかりません。
基本的に、これはあなたが呼んでいるWebサービスメソッドが、あなたが指定したパラメータシグネチャと共に見つけられないことを意味するでしょう。
10.4.5 404見つかりません
サーバーはRequest-URIに一致するものを見つけられませんでした。その状態が一時的なものか恒久的なものかは示されていません。
Gertが推奨 のような400 Bad Request
は有効な応答コードのままですが、通常は低レベルの問題を示すために使用されると思います。それは、不正なHTTPリクエスト、HTTPヘッダーがない、または無効である、あるいは同様のものとして簡単に解釈される可能性があります。
10.4.1 400不正なリクエスト
不正な構文のため、要求をサーバーで理解できませんでした。クライアントは変更なしにリクエストを繰り返すべきではありません(SHOULD NOT)。
あなたは400 Bad Requestコードを送ることができます。これは、より汎用性の高い4xxステータスコードの1つなので、意図したとおりの意味で使用できます。クライアントは、アプリケーションが正しく処理するために必要な情報やパラメータがない要求を送信しています。
APIプロジェクトの1つでは、パラメータがないために100%でいっぱいにできないときに、409ステータスを何らかの要求に設定することにしました。
HTTPステータスコード "409 Conflict"は、ユーザーが競合の原因を認識するのに十分な情報を含める必要があるため、私たちにとってはよい試みでした。
そのため、400や404などの他の応答の中で、要求内のいくつかのメモを調べて新しい正しい要求を設定するのに役立つことを強制するために409を選択しました。
いずれにしても、リクエストが完全に正しくなかった場合はデータイブを送信する必要があり、メッセージを見てリクエストで何が間違っていたのかを理解するようにクライアントに強制する必要があるためです。
一般的にいくつか欠けているパラメータしかない場合、400になります。そして欠けているパラメータの配列。しかし、特定のケースのメッセージのように、もう少し情報を送信する必要があるときに、クライアントがそれを確実に処理するようにしたい場合は、409を送信します。
必要なパラメータの中に何かがAPIエンドポイントが必要とするものと一致しない場合は通常422(処理不可能なエンティティ)ですが、不足しているパラメータの場合は406(許容できない)になります。
私はよく403 Forbiddenエラーを使います。推論は要求が理解されたということですが、私は尋ねられたようにするつもりはありません(物事が間違っているので)。レスポンスエンティティは何が問題なのかを説明しているので、レスポンスがHTMLページの場合、エラーメッセージはページにあります。それがJSONまたはXML応答の場合、エラー情報はそこにあります。
から rfc2616 :
10.4.4 403禁止されています
サーバーは要求を理解しましたが、それを満たすことを拒否しています。
承認は助けにならないでしょうし、要求は繰り返されるべきではありません。
リクエストメソッドがHEADではなく、サーバーが作成したい場合
公に要求が満たされなかった理由で、それは実体における拒絶の理由を説明すべきである。サーバがこの情報をクライアントに利用可能にしたくない場合は、ステータスコード404
代わりに(見つかりません)を使用できます。
指定されたリソースが見つからないため、404 Not Found
を使用する必要があると主張することができます。
この場合、Spring MVC(少なくとも3.x)は400を返しますが、これは私にとっては間違っているようです。
私はいくつかのGoogleのURL(accounts.google.com)をテストし、必要なパラメータを削除しました。この場合、通常404が返されます。
Googleをコピーします。