web-dev-qa-db-ja.com

REST-400を使用する場合( "Bad Request")

このsales/customers/{customerno}のようなリソースがあります。クライアントがこのリソースにPUTリクエストを送信する場合、エンティティ本文のxmlが有効なxmlでない場合、400-Bad requestを返します。しかし、xmlが有効であるが、xmlのコンテンツが有効でない場合はどうでしょう。たとえば、クライアントが顧客のPostCodeを更新しようとしており、無効なPostCodeを提供しているとします。 400を返すのは正しいですか?この場合、悪いリクエストですか、それとも別のhttpコードを使用する必要がありますか?

25
rgullhaug

From WikipediaのHTTPステータスコードのリスト

400 Bad Request:構文が正しくないため、リクエストを実行できません。

この場合、クライアントは、無効な構文の形式である無効な郵便番号を持つXMLペイロードを送信しました。したがって、400 Bad Requestを送信することは、この状況で返す適切なエラーコードです。

さらに、ウィキペディアはこのトピックのリソースとして RFC-4918 を引用しています。このドキュメントから、次の情報を見つけることができます。

サーバーは、400(Bad Request)ステータスコードと問題を説明するオプションの応答本文などで、疑わしいリクエストを拒否することができます(それらは整形式のXMLで構成されていますが)。

リクエストは整形式であるため(XMLは不良ではなく、意味的に間違った情報が含まれているだけです)、ステータスコード400でコンテンツを拒否できますmay。Word *may*は、他のオプションがあることを示唆しています。

ステータスコード422を使用したくなるかもしれませんが、無効なZipコードはセマンティックエラーであるという基準を満たさないため、この状況ではこれは正しくありません。以下をお読みください...

ウィキペディアから:

422 Unprocessable Entity(WebDAV; RFC 4918):要求は整形式でしたが、セマンティックエラーのために追跡できませんでした。

さらに、ここにいくつかの ステータスコード422の解釈を支援する定義

  • 構文エラーは、入力コードの解析中に発生し、文法的に正しくないステートメントが原因で発生します。典型的なエラーは、入力の不正な文字、行方不明の演算子、行の2つの演算子、セミコロンを挟まない同じ行の2つのステートメント、不均衡な括弧、誤った予約語などです。

  • コードが文法的に正しいと解析された後、コードの実行中にセマンティックエラーが発生します。これらは、ステートメントがどのように構築されるかではなく、それらが意味するものと関係があります。誤った変数のタイプまたはサイズ、存在しない変数、範囲外の添え字などのようなものは、セマンティックエラーです。

無効な郵便番号は、構文エラーでも意味エラーでもありません。したがって、ステータスコード422をオプションとして除外するのが妥当です。

質問に答えるには、ステータスコード400が適切です。ただし、他のオプションもあります。

31
jmort253

HTTP仕様の改訂版 here により、言い回しが更新され、約400が不正な形式のリクエストに限定されているという混乱を回避しています。

7.4.1。 400不正な要求

サーバーは、クライアントエラー(不正な構文など)のために、リクエストを処理できないか、処理しません。

17
Darrel Miller