400 BADリクエストHTTPエラーコードの意味？

HTTP URLに投稿しているJSONリクエストがあります。

これ400はrequestedResourceフィールドが存在する場所として扱う必要"Roman"がありますが、このフィールドには無効な値ですか？

[{requestedResource:"Roman"}] 

これ400は"blah"フィールドがまったく存在しない場所として扱う必要がありますか？

[{blah:"Roman"}]

400は、リクエストが不正な形式であることを意味します。言い換えると、クライアントからサーバーに送信されたデータストリームはルールに従っていませんでした。

JSONペイロードを持つREST APIの場合、通常、正確に言うと、サービスのAPI仕様に従って、JSONが何らかの方法で無効であることを示すために400が使用されます。

そのロジックにより、あなたが提供した両方のシナリオは400のはずです。

代わりに、これがJSONではなくXMLであったと想像してください。どちらの場合も、未定義の要素または不適切な要素の値が原因で、XMLがスキーマ検証に合格することはありません。それは悪い要求でしょう。ここで同じ取引。

w3.orgから

10.4.1 400不正なリクエスト

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

HTTP応答コードの選択は非常に簡単な作業であり、単純なルールで記述できます。しばしば忘れられる唯一のトリッキーな部分は、RFC 7231の段落6.5です。

HEADリクエストに応答する場合を除いて、サーバーは、エラー状況の説明と、それが一時的な状態か永続的な状態かを含む表現を送信する必要があります（SHOULD）。

ルールは次のとおりです。

1. リクエストが成功した場合、2xxコード（リダイレクトの場合は3xx）を返します。サーバーで内部論理エラーが発生した場合は、5xxを返します。クライアント要求に問題がある場合は、4xxコードを返します。
2. 選択したカテゴリから利用可能な応答コードを調べます。それらの1つがあなたの状況によく一致する名前を持っている場合は、それを使用できます。それ以外の場合は、x00コード（200、400、500）にフォールバックします。疑わしい場合は、x00コードにフォールバックしてください。
3. 応答本文でエラーの説明を返します。4xxコードの場合、クライアント開発者が理由を理解してクライアントを修正するために十分な情報が含まれている必要があります。セキュリティ上の理由から5xxの場合、詳細を明らかにする必要はありません。
4. クライアントがさまざまなエラーを区別し、それに応じてさまざまな反応をする必要がある場合は、機械可読で拡張可能なエラー形式を定義し、APIのあらゆる場所で使用します。最初から作成することをお勧めします。
5. クライアント開発者は奇妙なことをし、人間が読める記述として返す文字列を解析しようとする可能性があることに注意してください。そして、文字列を変更することによって、そのようなひどく書かれたクライアントを壊すでしょう。したがって、常に機械可読な説明を提供し、テキストで追加情報を報告しないようにしてください。

したがって、あなたの場合、ユーザー入力から "Roman"が取得され、クライアントが特定の反応を持つ必要がある場合、400エラーと次のようなものが返されます。

{
    "error_type" : "unsupported_resource",
    "error_description" : "\"Roman\" is not supported"
}

または、より一般的なエラー。このような状況がクライアントの論理エラーであり、開発者が何か間違っていない限り予期されない場合：

{
    "error_type" : "malformed_json",
    "error_description" : "\"Roman\" is not supported for \"requestedResource\" field"
}

どちらの場合も、「構文の誤り」ではありません。間違っているのはセマンティクスです。したがって、IMHO a 400は不適切です。代わりに、200などの何らかのエラーオブジェクトなどを返すことが適切{ "error": { "message": "Unknown request keyword" } }です。

クライアントの処理パスを検討してください。構文のエラー（無効なJSONなど）は、プログラムのロジックのエラー、つまりある種のバグであり、403と同様の方法でそれに応じて処理する必要があります。つまり、何か悪いことが起こったのです。

一方、パラメーター値のエラーはセマンティクスのエラーです。これは、おそらく妥当性が検証されていないユーザー入力によるものです。これはHTTPエラーではありません（ただし、422である可能性があります）。処理パスは異なります。

たとえば、jQueryでは、500のようなものといくつかのアプリ固有のセマンティックエラーの両方を処理する単一のエラーハンドラーを作成する必要がないことを好みます。Ember for oneなどの他のフレームワークも、400や500のようなHTTPエラーを大きなファットエラーと同じように扱います。プログラマーは何が起こっているのかを検出し、「実際の」エラーかどうかに応じて分岐する必要があります。

リクエストが不正な形式である400ことを示す以外の目的でステータスコードを使用することは、明らかに間違っています。

リクエストのペイロードに解析できないバイトシーケンスが含まれているapplication/json場合（サーバーがそのデータ形式を想定している場合）、適切なステータスコードは415次のとおりです。

リクエストのエンティティが、リクエストされたメソッドのリクエストされたリソースでサポートされていない形式であるため、サーバーはリクエストの処理を拒否しています。

リクエストのペイロードが構文的には正しいが意味的には正しくない場合は、非標準の422応答コードまたは標準の403ステータスコードを使用できます。

サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。承認は役に立たず、リクエストは繰り返されるべきではありません。

期待について考えます。

クライアントアプリとして、サーバー側で問題が発生したかどうかを知る必要があります。blahが見つからない場合、またはrequestedResource値が正しくない場合にサーバーがエラーをスローする必要がある場合は、400エラーが適切です。

補足として、私のものと同じ問題に遭遇する可能性のある人のために、$.ajaxフォームデータをサーバーに投稿するために使用していて400、最初にエラーも発生しました。

私はjavascript変数があると仮定し、

var formData = {
    "name":"Gearon",
    "hobby":"Be different"
    }; 

以下のようにformData、keyの値として変数を直接使用しないでくださいdata。

$.ajax({
    type: "post",
    dataType: "json",
    url: "http://localhost/user/add",
    contentType: "application/json",
    data: formData,
    success: function(data, textStatus){
        alert("Data: " + data + "\nStatus: " + status); 
    }
});

代わりに、JSON.stringifyを使用しformDataて以下をカプセル化します。

$.ajax({
    type: "post",
    dataType: "json",
    url: "http://localhost/user/add",
    contentType: "application/json",
    data: JSON.stringify(formData),
    success: function(data, textStatus){
        alert("Data: " + data + "\nStatus: " + status); 
    }
});

とにかく、他の人が示したように、エラーはサーバーがリクエストの形式が正しくない構文を引き起こしたことを認識できなかったためです。実際にはインスタンスを発生させています。それが誰かに役立つことを願っています。

最初に、URLが間違っている可能性があることを確認し、正しい場合は、送信しているリクエストの本文を確認します。考えられる原因は、送信しているリクエストに正しい構文がないことです。

詳細については、リクエスト文字列に特殊文字がないか確認してください。（特殊文字）が使用されている場合、これがこのエラーの根本的な原因です。

リクエストをコピーして、すべてのタグデータを分析してみてください。