これは、WeChat パブリック プラットフォーム インターフェイスのリターン コードです。プロジェクトで作業する場合、API インターフェースのリターン コードが必要になります。API インターフェースのリターン コードの設計方法を知りたいですか?
私が言いたいのは、異なる意味を表す異なるリターン コードをどのように設計するかということです。たとえば、40001 は XXX を意味し、40002 は XXX を意味します。これらはこのように設計する必要がありますか?みんなありがとう###
拥有18年软件开发和IT教学经验。曾任多家上市公司技术总监、架构师、项目经理、高级软件工程师等职务。 网络人气名人讲师,...
アプリケーション開発では、エラー コードよりもエラー名を使用する方が適切であり、コードが読みやすくなります。
クライアントコードを想像してください:
vs
国内の API プロバイダーは、国内の開発者が英語に慣れていない (または API 開発者自身が英語の名前を覚えていない) ことを考慮して、数値のエラー コードを使用することがあります。
デジタル コードは、伝送効率が高いため (バイナリ プロトコルなど)、多くの JSON 形式の文字列伝送プロトコルでは、この効率は重要ではありません。
読みやすさははるかに重要であり、エラー名には、エラー コードと比較して構造化されておらず、拡張性があるという利点があります。
私の考えを教えてください。 特殊なリターン コード: (すべてのインターフェイスに共通) 0、成功を表します。 -1、内部サーバー エラーを表します。 一般的なエラーのリターン コード: 最初の数字は、別のインターフェイスに戻ることを表します。 残りは次のとおりです。エラーの種類。重要度の降順に並べられています。
実際には、そこまで深く学ぶ必要はないと思います。 WeChatに似ています。 重要なのはシンプルにすることです。
Microsoft から学ぶことができます。たとえば、ERROR_SUCCESS は 0 で、これは成功を意味します。エラー コードは 1 から始まり 10,000 を超えるまで定義されています。次に、エラー コードを 1 ~ 1000、1001 ~ 2000、2001 ~ 3000 などのいくつかの間隔に分割して、それぞれがどのような種類の意味を表すかを決定します。その後、基本的なエラー コードから始めて各間隔を定義できます。と考えることができ、それから少量で増幅することもできます。
リーリー
アプリケーション開発では、エラー コードよりもエラー名を使用する方が適切であり、コードが読みやすくなります。
クライアントコードを想像してください:
リーリーvs
リーリー国内の API プロバイダーは、国内の開発者が英語に慣れていない (または API 開発者自身が英語の名前を覚えていない) ことを考慮して、数値のエラー コードを使用することがあります。
デジタル コードは、伝送効率が高いため (バイナリ プロトコルなど)、多くの JSON 形式の文字列伝送プロトコルでは、この効率は重要ではありません。
読みやすさははるかに重要であり、エラー名には、エラー コードと比較して構造化されておらず、拡張性があるという利点があります。
私の考えを教えてください。
特殊なリターン コード: (すべてのインターフェイスに共通)
0、成功を表します。
-1、内部サーバー エラーを表します。
一般的なエラーのリターン コード:
最初の数字は、別のインターフェイスに戻ることを表します。
残りは次のとおりです。エラーの種類。重要度の降順に並べられています。
実際には、そこまで深く学ぶ必要はないと思います。
WeChatに似ています。
重要なのはシンプルにすることです。
Microsoft から学ぶことができます。たとえば、ERROR_SUCCESS は 0 で、これは成功を意味します。エラー コードは 1 から始まり 10,000 を超えるまで定義されています。次に、エラー コードを 1 ~ 1000、1001 ~ 2000、2001 ~ 3000 などのいくつかの間隔に分割して、それぞれがどのような種類の意味を表すかを決定します。その後、基本的なエラー コードから始めて各間隔を定義できます。と考えることができ、それから少量で増幅することもできます。
リーリー