HTTP プロトコルの戻りステータス コード仕様の問題

クライアントがサーバーにリクエストを送信した後、サーバーはデータと一致しないことが判明し、エラーを返す必要があるとします。

私の理解では、クライアントのリクエストプロセスは正しいため、データ形式がサーバーの要件を満たしていない場合でも、サーバーはステータスコード200を返し、テキストまたはjsonでエラーメッセージを返す必要があります。メッセージをフォーマットします。実際のステータス コードをメッセージに添付します。

しかし、他の人のインターフェースを見たところ、510 ステータス コードを直接返した人もいました。

すみません、どう思いますか？どれが標準ですか?

返信内容:

クライアントがサーバーにリクエストを送信した後、サーバーがデータと一致しないことが判明し、エラーを返す必要があるとします。

私の理解では、クライアントのリクエストプロセスは正しいため、データ形式がサーバーの要件を満たしていない場合でも、サーバーはステータスコード200を返し、テキストまたはjsonでエラーメッセージを返す必要があります。メッセージをフォーマットします。実際のステータス コードをメッセージに添付します。

しかし、他の人のインターフェースを見たところ、510 ステータス コードを直接返した人もいました。

すみません、どう思いますか？どれが標準ですか?

インターネット上の多くのインターフェースは、ほとんどが準拠していないものであり、HTTP プロトコルを理解していない人々によって作成された HTTP サービスです。だから、それについては気にしないでください。 PHP がハッカーを惹きつける理由もこれと似ています。この問題を積極的に掘り下げてくださったことに大変感謝しており、その精神を称賛しなければなりません。

実際、この本「The Definitive Guide to HTTP」を購入することをお勧めします。この本は、あなたのような意欲的な人々に非常に適しています。

実際、この質問に対するあなたの理解は偏っています。

リクエストプロセスが正しいからといって、レスポンスが200である必要があるという意味ではありません。レスポンスが得られるということは、リクエストの処理に問題がないことを意味しており、DNS例外や接続タイムアウトなどのリクエスト処理が間違っている場合は、リクエストすらできなくなります。応答コードを参照してください。

したがって、応答コードは、リクエストに応じて HTTP サーバーによって与えられた結果を識別するために使用されます。

このため、主に 2xx、3xx、4xx、5xx に分かれています。2 で始まるものは確実に成功し (200 だけではありません)、3 で始まるものは通常正常ですが、リソースが直接得られるわけではありません。 302 リダイレクト、期限切れでない 304 キャッシュなどのリクエストによって取得されます。

ここが重要なポイントです。4 で始まる数字は、いわゆる送信されたデータ形式が間違っている (400 または 422)、リクエストには承認が必要である (401)、または何らかの理由 (権限が不十分である) によりリクエストが拒否されたことなど、リクエストの異常を示すことがよくあります。要求されたデータが存在しない場合、または現在の要求でデータを取得したくない場合は、404 を使用します (非常によく知られています)。要求メソッドが拒否された場合は、405 を使用します。たとえば、PUT を使用する必要があります。データを変更するには POST、データを取得するには GET、データを削除するには DELETE リクエストを使用します (もちろん、4 で始まる応答コードが最も一般的です)。百科事典で HTTP ステータス コードに関する詳細な記事を見つけることができます (百科事典が何であっても)。

5 で始まるものは主にサーバー エラーです。リクエスト エラーが原因ではない例外は、500 サーバー例外や 503 サーバーがサービスを提供できないなど、すべて 5 で始まるステータス コードです。

HTTP ステータス コードは一連の RFC 標準文書で定義されているため、すべてのインターフェイス プロンプトの詳細に完全に適応することはできませんが、ほとんどの応答のセマンティクスを完全にカバーできます。詳細なプロンプトの場合、詳細な問題に対する HTTP ステータス コードの表現力の不足を補うために、インターフェイス応答に別のステータス応答コードが設定されることがよくあります。たとえば、リクエストの形式は間違っていますが、特定のパラメータが欠落しているか、指定されているパラメータが多すぎて、両方とも 400 です。何が起こったのかをクライアントに明確に知らせたい場合は、インターフェイスで何か追加のものを定義して支援する必要があります。このような状況。

この質問は実際には、特定のアプリケーション シナリオと組み合わせる必要があります。

まず第一に、クライアントがアプリ、特にモバイルアプリを参照する場合、200 と特定のエラー コードを使用するのが正しい選択です。これはもっと合理的ではありませんが、中国（まあ、実際には外国もあります）にはHTTPハイジャックと呼ばれる国情があります。 404や500は運営者等に直接乗っ取られる可能性があります（笑）。あなたが返す追加の http エラー情報は、アプリでは受信されません。したがって、工場 A、工場 B、および工場 T のパブリック ネットワーク プロトコルを見ると、すべてこの方法でエラーが送信されます。設計者や設計者が Restful ステータス コードと HTTP ステータス コードを理解していないわけではありません。

それが内部プロトコルであり、サービス間であり、環境が保証されている場合は、標準の RESTful 形式でエラーを定義できます。

条件があり、標準の HTTP ステータス コードの形式でエラー プロトコルを使用したい場合は、写真を共有してください。

さまざまな仕様にはそれぞれ独自の理由があります。あなたが言及した 2 つのステータス コードの 1 つは、ステータス コードを分析するための主な参照として http リクエストを使用することです。もう 1 つは、ステータス コードを分析するための主な参照として独自のインターフェイスを使用することです。 。どちらにも独自の理由があり、使用シナリオによって異なります

それは標準化されていますか? それとも会社のリードに従っていますか? 個人的には、エラーを返してエラーメッセージを表示するために http ステータスコードを使用することを好みます。

それは間違っています。200 ステータス コードではありませんが、他のステータス コードにも対応するコンテンツまたは json が含まれている可能性があります。これは Spring MVC で利用可能だったようです。この関数は、検証に使用される限り、ステータス コード 400 を返し、json を返します。

これはプロジェクトがどのように規制されているかによって異なります。 http メソッドに従うことも、自分で設定することもできます。たとえば、このエラー ステータス コードを受け取った場合は、自分で新しいステータス コードを設定し、いくつかの情報プロンプトを返します。

プロジェクト全体の仕様が優先される場合もあります。

Tencent の WeChat 開発ドキュメントを参照してください。
これらはすべて統一インターフェイスの戻り値です。
http ステータス コードは基本的に 200 です。
エラーを定義するには、異なる error_codes を使用します。

個人的な意見

httpステータスコードを使用するのは正しいです。

510 わからないので、私がよく書くステータスコードを教えてください。

http ステータス 400 および 403。

前者は、通常はパラメーターに問題があるため、リクエストを解析できないことを意味します。ほとんどの場合、このエラーを判断するためのコードを記述する必要はなく、サーバー プログラムが自動的に判断してこのステータスを返します。

たとえば、私のパラメータでは 1 から 10 までの数値のみを渡すことができます。ユーザーがランダムなパスを実行した場合、このステータス コードを返します。

後者は、構成で設定されたいくつかの禁止されたアクセス パスに加えて、ユーザーにアクセス権限がないことを意味し、多くの場合、権限を決定するコードを記述する必要があります。

たとえば、私のバックエンドは、特定のリクエスト ヘッダーを持つ特定の IP とマシンからのアクセスのみを許可し、他のすべてのマシンはこのステータス コードを返します。

---

200 + json を使用してステータス コードを返す場合、これらの標準の http ステータス コードの意味は基本的に役に立ちません。設計者はすでにそれを 200 と 404 のみに簡略化していました。 404 であっても json ステータス コードを使用できます。接続されているかどうかを示すには 200 を使用するだけです。

ステータスコードの利点は何ですか?

最新のブラウザと検索エンジン クローラーは http ステータス コードを認識し、部分的に処理します

例:

ステータス コード

4xx は、現在の URL が正しくないことを意味し、リクエストを再送信しても意味がありません。
ページの 1 つが http 200 + json 400 を返した場合、そのパラメータに問題があることを意味します。

検索エンジンはカスタム ステータス コードを解析せず、当然のことながらこのデータが誤って含まれてしまいます。
一部のユーザーは、検索エンジンを通じて間違ったパラメータを含むページにジャンプします。

ブラウザは、カスタム ステータス コードを解析しません。また、ブラウザはアクセス記録を自動的に記録し、ブラウザは 400、403、404 などのステータス コードを受信した場合、閲覧記録を保存しません (Chrome は次のとおりです)。他の人も同様のようです)。

200 を返した後は、ユーザーが URL を入力するときにブラウザーのプロンプト レコードをクリックする可能性が高く、その結果、間違った接続に再度アクセスすることになります。