1

POSTリクエストが検証に失敗したため（たとえば、電子メールアドレスが見つからない）、HTTPサーバーが400応答コードでに応答するとします。サーバーがエラーの性質についてより多くの情報をクライアントに提供したい場合、これはどのように返されるべきですか？リクエストで使用される可能性のあるコンテンツタイプごとに、理想的には関連する「エラー」コンテンツタイプが必要ですか？

たとえば、リクエストが与えられた場合

POST /users
Content-Type: application/x-myuser

{
    "email": "foo@example.com",
    "name": "Michael"
}

応答は

400 Bad Request
Content-Type: application/x-myuser-error

{
    "email": "Email address foo@example.com not found"
}

公開されている「エラー」コンテンツタイプの良い例はありますか？

4

1 に答える 1

1

例はありませんが、次のことを常に念頭に置いておくことをお勧めします。

  • 常に機械可読エラーを含め、可能な限り一般化してください。のような JSON 構造

    {"error":"Email address not found!","code":"fielderror","field":"email","reason":"notfound"}( に簡略化できます{"error":"...","code":"emailnotfound"})

    API 開発者はユーザーにエラーを適切に表示 (およびエラーに対処) でき、アプリケーションを壊さずにメッセージを変更できます。また、ユーザー側と外部開発者側の両方で、エラー メッセージの翻訳にも役立ちます。

  • 別のアプローチは、単に本文を返さず、HTTP ヘッダーを使用してユーザー エージェントに何が問題なのかを伝えることです。たとえば、 と を使用X-ErrorしX-Error-Codeて、人間が判読できるエラーと機械が判読できるコードを表示できます。
  • あまりにも多くのコンテンツ タイプを作成することは、悪いことかもしれません。application/json個人的には、HTTP コード 200、400、403、404、500 などを常に使用して、ユーザー エージェントにステータスを知らせることを好みます。
  • HTTP コードとコンテンツ タイプを組み合わせて作成することは絶対にやめてください。application/myapp/error編集画面にいる場合は 200 で、エラーが 302 の場合は実際にはエラーではなくリダイレ​​クトです。これが、おそらく 1 つのコンテンツ タイプに固執する必要がある理由です。

結論: 常にシンプルに保ちます。ステータスを検出するときは、2 つまたは 3 つではなく、 1 つのフィールドを確認する必要があります。ユーザー エージェントがステータスを判断したら、追加情報を得るために他のフィールドを調べることを選択できますが、それは何かがうまくいかなかったと判断した後でのみです。個別のコンテンツ タイプを含めても、おそらく役に立たないでしょう。

于 2012-04-23T14:37:08.413 に答える