httpステータスコードの使用に関する問題

フロントエンドとして、私は最近バックエンドを書き始めました、そして、いくつかの安静な設計の問題に遭遇しました、あなたがそれらに答えられることを願っています。
Restful 仕様では、HTTP ステータス コード の使用が特に強調されていますが、使用する際にはいくつかの疑問があります。特にエラーメッセージを返す分野です。 HTTP Status Codes的使用，但是我在使用的时候却有一些疑惑。尤其是在返回错误信息这块。
我自己使用时是约定好一套关于业务的错误码，比如20001,代表'缺少xxx字段',把他放在http response body里面返回，然后在response头里面写好200 OK之类的。
比如login的时候,假如前端传过来的json里面没有password字段,
那我返回一个400 Bad Request私自身が使用するときは、「xxx フィールドが欠落している」ことを表す 20001 などの一連のビジネス関連のエラー コードに同意し、それを http 応答本文に入れて返し、応答に 200 OK と書き込みます。ヘッダ。

たとえば、ログイン時に、フロントエンドによって渡された JSON にパスワード フィールドがない場合、

400 Bad Request の http メッセージとメッセージの本文部分を返します。は次のとおりです (例を挙げるだけです)。すべてを単純にしてください):
リーリー 400 Bad Request肯定不对吧,人家前端传过来的信息没有问题,401 Unauthorized 403 Forbidden之类的感觉也不能用在这,所以这个时候的HTTP Status Codes状态码到底应该用什么呢?
确实有很多同学在使用时是不管什么情况都返回200 OK,然后在http body部分用json去返回错误信息,但我还是觉得HTTP Status Codes上記の処理方法についての主な質問は次のとおりです。

時々ビジネス エラーが発生し、どの HTTP ステータス コードを使用すればよいかわかりません。たとえば、新しいユーザーを作成するときに、そのユーザー名が既に存在する場合は、使用しません。この時点で本体部分を知るのは簡単ですが、どの HTTP ステータス コードを使用する必要がありますか? 400 Bad Request それは間違っているはずです。フロントエンドから送信された情報は問題ありません。 401 Unauthorized 403 Forbidden Feelings like はここでは使用できません。では、この時点で HTTP ステータス コードには何を使用する必要がありますか? 実際、多くの学生は 200 OK を返します。 code> を使用するときの状況に関係なく、json を使用して http body 部分にエラー情報を返しますが、それでも HTTP Status Codes は次のとおりだと思います。これはrestfulの非常に重要な部分であり、restful仕様でもその使用法が強調されているため、この部分を行う方法について皆さんが明確な道筋を示してくれることを私は依然として望んでいます。

返信内容:
HTTP Status Codes的使用，但是我在使用的时候却有一些疑惑。尤其是在返回错误信息这块。
我自己使用时是约定好一套关于业务的错误码，比如20001,代表'缺少xxx字段',把他放在http response body里面返回，然后在response头里面写好200 OK之类的。
比如login的时候,假如前端传过来的json里面没有password字段,
那我返回一个400 Bad Requestフロントエンドとして、私は最近バックエンドを書き始めました、そして、いくつかの安静な設計の問題に遭遇しました、あなたがそれらに答えられることを願っています。

Restful 仕様では、HTTP ステータス コード の使用が特に強調されていますが、使用する際にはいくつかの疑問があります。特にエラーメッセージを返す分野です。

私自身が使用するときは、「xxx フィールドが欠落している」ことを表す 20001 などのビジネス関連の一連のエラー コードに同意し、それを http 応答本文に入れて返し、応答に 200 OK と書き込みます。ヘッダ。
たとえば、ログイン時に、フロントエンドによって渡された JSON にパスワード フィールドがない場合、400 Bad Request肯定不对吧,人家前端传过来的信息没有问题,401 Unauthorized 403 Forbidden之类的感觉也不能用在这,所以这个时候的HTTP Status Codes状态码到底应该用什么呢?
确实有很多同学在使用时是不管什么情况都返回200 OK,然后在http body部分用json去返回错误信息,但我还是觉得HTTP Status Codes 400 Bad Request の http メッセージとメッセージの本文部分を返します。は次のとおりです (例を挙げるだけです)。すべてを単純にしてください):

リーリー

上記の処理方法についての主な質問は次のとおりです。

時々ビジネス エラーが発生し、どの HTTP ステータス コードを使用すればよいかわかりません。たとえば、新しいユーザーを作成するときに、そのユーザー名が既に存在する場合は、使用しません。この時点で本体部分を知るのは簡単ですが、どの HTTP ステータス コードを使用する必要がありますか? 400 Bad Request それは間違っているはずです。フロントエンドから送信された情報は問題ありません。 401 Unauthorized 403 Forbidden Feelings のような はここでは使用できません。では、この時点で HTTP ステータス コードには何を使用する必要がありますか?

実際、多くの学生は 200 OK を返します。 code> を使用するときの状況に関係なく、json を使用して http body 部分にエラー情報を返しますが、それでも HTTP Status Codes は次のとおりだと思います。これはrestfulの非常に重要な部分であり、restful仕様でもその使用法が強調されているため、この部分を行う方法について皆さんが明確な道筋を示してくれることを私は依然として望んでいます。

233 ok http ステータス コードのリストを確認することをお勧めします。一般に、4xx 応答コードも多数あります。

仕様は一般的な提案にすぎません。仕様を作成することもできます。重要なのは、適切な調整を行い、関連する文書を残すことです。

🎜 ウェブサイト型のプログラムで使用されていると仮定します。端的に言えば、ウェブサイトはユーザーが見るためのものです。確かにウェブページは存在せず、404 が返されますが、通常はウェブサーバーがこれを実行します。ただし、問題が発生したときにサーバーを使用するだけでは十分ではありません。Web サイトは、ユーザーがどれだけ科学的にリターン コードを設定したかを気にしません。リターンコードをいじってみます。したがって、Web サイトの場合、一般的に使用されるリターン コードを指定できますが、焦点は表示されるページにあります。リターン コードが 400 なのか 401 なのかについては、どんなにこだわっても、エラー メッセージ プロンプト ページほど簡潔で明確ではありません。 🎜

API タイプのアプリケーションの場合、API がフロントエンド Ajax 用であると仮定すると、ビジネス ロジックが失敗したときに HTTP プロトコルのステータス コードを与えると、コンソールにエラー ログが出力されるだけです。 jquery で処理された ajax を使用している場合、エラー関数のコールバックがトリガーされますが、これは間違いなく、エラー情報フィールドに戻りコードとエラー情報が含まれる json データを返すことになります。 json内に表示されます。エラーが発生したときにリターン コードを使用すると、エラー コールバックで特定のエラー原因を取得できなくなります。操作 xxx でエラーが発生したという漠然としたメッセージを表示することしかできません。これはユーザーが望んでいることではありません。これにより、顧客サービスの難易度も高まり、ユーザーは顧客サービスに問題を説明するときに漠然とした問題しか説明できなくなります。もちろん、リバース プロキシを使用すると、フロントエンド プログラムは、現在の不正なリターン コードが Web アプリケーションから返されたのか、リバース プロキシ サーバーから返されたのかを区別できなくなります。

純粋なサーバー間の API 間でカスタム HTTP リターン コードを使用すると、開発者は HTTP リターン コードを解析するだけでは不十分であることがわかります。この場合、エラーの詳細を知る必要があります。 jsonデータ。もちろん、前述のリバース プロキシの問題はここでもまだ存在します。

まとめると、カスタム HTTP リターン コードの使用は非常に科学的ではありますが、あまりにも学術的で非現実的です。特に Web サイトのアプリケーションでは、リンクが見つからない場合やキャッチされない例外が発生した場合に 404 または 500 が返されるため、戻るときにそれを伝えるためにフレンドリーなエラー ページを使用する必要があります。他の論理エラーも同様にエラー ページで伝える必要があります。可能。

422 処理できないエンティティ - [POST/PUT/PATCH] オブジェクトの作成時に検証エラーが発生しました。

これはいい感じ

422 処理できないエンティティ - [POST/PUT/PATCH] オブジェクトの作成時に検証エラーが発生しました。

このヒントも良いです

情報が矛盾している場合は、409 Conflict を使用することもできます

ここで HTTP ステータス コード分析をチェックできます
http://jingyan.baidu.com/arti...