応答本文内にエラーを含むHTTP 200 OKを返す

Question

サーバー側でエラーが発生し、応答本文内に何らかのエラーが発生したときにHTTP 200 OKを返すのが正しいかどうか疑問に思っています。

例：

http GETを送信しています
サーバー側で予期しないことが起こりました。
サーバーは、応答内にエラーを含むhttp 200 OKステータスコードを返します（例：{"status":"some error occured"}

正しい動作ですか？ステータスコードを変更する必要はありませんか？

Julian Reschke · Accepted Answer

いいえ、これは非常に間違っています。

HTTPはアプリケーションプロトコルです。 200は、応答に、要求されたリソースのステータスを表すペイロードが含まれることを意味します。通常、エラーメッセージはそのリソースの表現ではありません。

GETの処理中に問題が発生した場合、正しいステータスコードは4xx（「あなたが台無しになった」）または5xx（「台無しになった」）です。

geert3 · Answer

HTTPステータスコードは、HTTPプロトコルに関する情報を示します。 HTTP 200は、HTTPレベルで送信が正常であることを意味します（つまり、要求は技術的には正常であり、サーバーは適切に応答できました）。すべてのコードとその意味のリストについては、このwikiページを参照してください。

HTTP 200は、「ビジネスコード」の成功または失敗とは関係ありません。この例では、HTTP 200は、ビジネスロジックの正常な実行を妨げる技術的な問題がない限り、「ビジネスコードエラーメッセージ」が正常に転送されたことを示す許容ステータスです。

または、サーバーで技術的または回復不可能な問題が発生した場合、サーバーにHTTP 5xxで応答させることができます。またはHTTP 4xx着信リクエストに問題がある場合（例：間違ったパラメーター、予期しないHTTPメソッド...）繰り返しますが、これらはすべてtechnicalエラーを示します。 HTTP 200はNO技術的エラーを示しますが、ビジネスロジックエラーについては保証しません。

要約すると、はい。HTTPステータス200とともにHTTP応答でエラーメッセージ（非技術的な問題の場合）を送信することは有効です。これがあなたのケースに当てはまるかどうかはあなた次第です。たとえば、クライアントが存在しないファイルを要求している場合、それは404に似ています。サーバー上に500である可能性のある構成の誤りがある場合。クライアントが満席の飛行機の座席を求めた場合、それは200となり、あなたの「実装」がこれを認識/処理する方法を指示します（例：{ "booking","failed" }のJSONブロック）

Alexanderius · Answer

HTTPコードとしてビジネスロジックエラーを返したい場合でも、実際のエラーを誤って表すため、HTTP 200を使用するのではなく、そのエラーに対してそのような許容可能なHTTPエラーコードはありません。

したがって、HTTP 200はビジネスロジックエラーに適しています。ただし、HTTPエラーコードでカバーされるすべてのエラーはそれらを使用する必要があります。

基本的にHTTP 200は、どのサーバーがユーザーリクエストを正しく処理するかを意味します（飛行機に座席がない場合、ユーザーリクエストが正しく処理されたからといって、飛行機で利用できる座席の数だけを返すことさえできるので、ビジネスロジックエラーがまったくないか、そのビジネスロジックがクライアント側に存在する可能性があります。ビジネスロジックエラーは抽象的な意味ですが、HTTPエラーはより明確です。

vedant · Answer

明確にするために、プロトコルに適合する場所でHTTPエラーコードを使用し、ビジネスロジックエラーを送信するためにHTTPステータスコードを使用しないでください。

残高不足、利用可能なタクシーなし、不良ユーザー/パスワードのようなエラーHTTPステータス200の場合、応答本文にアプリケーション固有のエラー処理があります。

このソフトウェアエンジニアリングの答えを参照してください。

プロトコルの分離について明示する方が良いと思います。 HTTPサーバーとWebブラウザーに独自の処理を実行させ、アプリにits独自の処理を実行させます。アプリは要求を行うことができる必要があり、応答が必要です。要求の方法、応答の解釈方法に関するロジックは、HTTPパースペクティブよりも複雑（または複雑ではない）にできます。

Chris Groves · Answer

HTTPは、インターネットを介したデータの送信を処理するプロトコルです。

その送信が何らかの理由で中断した場合、HTTPエラーコードは、送信できない理由を示します。

送信されるデータは、HTTPエラーコードによって処理されません。送信方法のみ。

HTTPは「わかりました、この答えはgobbledigookですが、ここにあります」とは言えません。 200 OKとだけ書かれています。

すなわち：私はあなたにそれを手に入れる私の仕事を完了しました、残りはあなた次第です。

これはすでに回答されていますが、理解できる言葉で説明しています。繰り返してすみません。

snarf · Answer

人々は、プロトコルの問題よりもアプリケーションロジックを重視しすぎていると思います。重要なことは、応答が理にかなっていることです。動的リソースを提供するAPIがあり、データYを含むテンプレートYから派生したXに対してリクエストが行われ、YまたはZが現在利用できない場合はどうなりますか？それはビジネスロジックのエラーですか、それとも技術的なエラーですか？正しい答えは、「誰が気にしますか？」です。

APIと応答はわかりやすく、一貫している必要があります。何らかの仕様に準拠する必要があり、その仕様は有効な応答とは何かを定義する必要があります。有効な応答に適合するものは、200コードを生成するはずです。有効な応答に適合しないものは、有効な応答を生成できなかった理由を示す4xxまたは5xxコードを生成する必要があります。

仕様の有効な応答の定義で{ "error": "invalid ID" }が許可されている場合、成功の応答です。仕様がその対応を行わない場合、200コードでその応答を返すことは不適切な決定になります。

関数parseFooを呼び出すことに例えます。 parseFoo("invalid data")を呼び出すとどうなりますか？エラー結果（nullの可能性があります）を返しますか？または、例外をスローしますか？多くの人はどちらかのアプローチが正しいかどうかについてほぼ宗教的な立場を取りますが、最終的にはAPI仕様次第です

「ステータスコード要素は、リクエストを理解して満足させる試みの結果を与える3桁の整数コードです」

「エラーを正常に返すこと」がHTTPの成功またはエラーを構成するかどうかに関して、明らかに意見の相違があります。同じ仕様を異なる方法で解釈している人がいます。したがって、どちらか一方を選んでください。しかし、いずれにしても、全世界があなたに同意するわけではないことを受け入れてください。私？私は自分自身を途中で見つけますが、常識的な考慮事項をいくつか提供します。

サーバー側のコードがリクエストのディスパッチ時に予期しない例外をキャッチした場合、それはまさに500 Internal Server Errorの定義のように聞こえます。 これはOPの状況のようです。アプリケーションは、予期しないエラーに対して200を返すべきではありませんですが、ポイント3も参照してください。
サーバー側のコードが指定された無効な入力を適切に処理でき、「例外的な」エラー状態を構成しない場合、仕様should意味のある診断情報を提供するHTTP 200応答に対応します。
とりわけ：仕様を作成します。一貫性を保ちます。それに固執します。

OPの状況では、未処理の例外が区別可能な応答本文を持つ200を生成する事実上の標準があるように思えます。それは理想的ではありませんが、物事を壊して積極的に問題を引き起こしていない場合は、おそらくより大きな、より重要な問題を解決する必要があります。