web-dev-qa-db-ja.com

リクエストは成功したが警告メッセージが表示された場合の適切なHTTPステータスコードは何ですか？

RESTを適切に使用する場合、リクエストが成功したが警告メッセージが表示された場合のHTTPステータスコードは何が適切ですか？

私たちの場合には;クライアントは、ブラウザで実行されるWebアプリケーションです。次のようなステータスコードをお勧めします。

  • リクエストが正常に処理されたときのHTTP200、201、204
  • リクエストが一部のビジネスルールに違反している場合のHTTP422
  • リクエストの処理中に予期しない例外が発生した場合のHTTP500

しかし、リクエストが正常に処理されたときにどのステータスコードを使用するかを決定できませんでしたが、いくつかの情報または警告メッセージをクライアントに送信する必要がありますか？

resthttp-status-codesjson-apihttp-status
12
ykaragol

HTTPプロトコルには、実際には「警告」ヘッダーがあります（ ヘッダーフィールドの定義 を参照）。これらはHTTP警告ですが、コード199を使用して必要なものを送信できます。

199その他の警告警告テキストには、人間のユーザーに提示する、またはログに記録する任意の情報を含めることができます。

ここでの問題は、仕様の次のビットです。

この警告を受け取ったシステムは、ユーザーに警告を表示する以外に、自動化されたアクションを実行してはなりません（MUSTNOT）。

このため、応答コンテンツに警告に関するデータを追加する方がよいと思います（そして、200ステータスコードを引き続き使用します）。

10
ChatterOne

HTTPステータスコードは、リクエストが適切に進行したかどうかを判断し、警告ステータスはありません。内部機能の結果に関する情報を提供する場合は、応答コンテンツに情報ステータスを追加する必要があります。例：

{
    status: "WARNING",
    code: "WARNING-CODE"
}
1
Blady214

同様のケースで、HTTP 418を使用しました（see[〜＃〜] htcpcp [〜＃〜] ）

クライアントは、Google MapsAPIを使用して地図タイルを表示するウェブアプリでした。そして、意図的に空白のタイル（ゼロデータ-> HTTP 200の空白タイル）と欠落データに起因する空白のタイル（nullデータ-> HTTP 418の空白タイル）を区別したかったのです。

404を返すと、応答本文にタイルを送信できなくなり、マップ上に醜いシンボルが配置されていました。ただし、418を返すと、応答本文が許可され（おそらく、HTTP 418を取り巻く深刻な標準定義がないためですか？）、同時に、診断目的で使用するためにログなどで簡単にフィルタリングできるステータスコードが提供されます。

0
Kenigmatic