web-dev-qa-db-ja.com

HTTPヘッダーまたは応答本文にエラーメッセージを保存しますか？

REST iPhoneに公開されているサービスとAndroidクライアント。現在、HTTPコード200、400、401、403、404、409、 500など.

私の質問は、エラーの理由/説明/原因を置くための推奨場所はどこですか？ REST APIが常にヘッダーにカスタムReasonを含むようにすると、より理にかなっていますか？

< HTTP/1.1 400 Bad Request - Missing Required Parameters.
< Date: Thu, 20 Dec 2012 01:09:06 GMT
< Server: Apache/2.2.22 (Ubuntu)
< Connection: close
< Transfer-Encoding: chunked

または、JSONを介して応答本文に含める方が良いでしょうか？

< HTTP/1.1 400 Bad Request
< Date: Thu, 20 Dec 2012 01:09:06 GMT
< Server: Apache/2.2.22 (Ubuntu)
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: application/json
{ "error" : "Missing Required Parameters" }
httpresthttp-error
72
James Cowhen

400.xエラーコードのHTTP仕様から引用：

ステータスコードの4xxクラスは、クライアントが誤っているように見える場合を対象としています。 HEADリクエストに応答する場合を除き、サーバーは、エラー状態の説明と、それが一時的な状態か永続的な状態かを含むエンティティを含める必要があります。これらのステータスコードは、すべてのリクエストメソッドに適用できますユーザーエージェントは、含まれるエンティティをユーザーに表示する必要があります。

エラーメッセージをHTTP応答の本文にエンティティとして含めることをお勧めします。JSON、プレーンテキスト、フォーマットされたHTML、またはその他の利用可能なフォーマットです。

83
Perception

本文にエラーの詳細を含めることをお勧めします。さらに、多く（ほとんど/ほとんどすべて、たとえばWSGI）のサーバーとクライアントはエラーコードの名前の変更をサポートしていません-それらを固定ペアとして扱います（たとえば、400は常に「Bad Request」ではなく「Bad Request」ですユーザーIDの指定を忘れました」）。たとえ壊れていなくても、特定のエラーコードの特別な名前は気にしません。

22
Tadeck

エラーは本体に属していません。警告ヘッダーに属します。

警告の一般的なHTTPヘッダーには、メッセージのステータスに関する考えられる問題に関する情報が含まれています。

参照

2
B Seven

私は常に両方を行います。通常、ステータスメッセージは、「409-新しいユーザーを追加できませんでした。既に存在します」など、フロントエンドがユーザーにわかりやすい方法で表示できるものに設定します。

次に、エラー条件の詳細を本文にJSONとして含めて、UI開発者が何をするかについて賢明な選択を行えるようにします。

{
  "status": 409,
  "message": "The user <username> was already added on <when> by <who> and given the user id 12345.",
  "errors": {
    "id": 12345
  }
}
0
Matthew Purdon