API例外のトラブルシューティング方法
1. 簡単なトラブルシューティング
1. 簡単なトラブルシューティングのフローチャート
フローチャートでの問題の詳細な説明
API 以外の問題
開発者がタオバオに HTTP リクエストを送信する前に発生する問題タオバオのビジネス上の問題、ビジネス上の問題、コンテナエラーの問題などのデータ。
1. タオバオのビジネス上の問題:
(1) ビジネス ルールの問題 (製品やユーザーが罰せられるなど)
(2) タオバオ ページでの操作の失敗例: タオバオ バックエンドでセール中の商品を表示できないなど。
2. ビジネス上の問題:
(1) アプリケーション アクセスの問題。たとえば、次のようなアプリケーション アクセスの問題です。開発者登録など
(2) アプリケーションのレビューの問題、たとえば、どのアプリケーションがアクセスをサポートしていないのかなど。
(3) アプリケーションのオンラインの問題、たとえば、次のようなもの。呼び出し頻度など
3 . コンテナ エラーの問題:
コンテナを通じて、ユーザーは開発者がデータ情報 (主にページ上のエラー コード 100 ～ 200 のエラー) を取得することを承認できます。
API の問題
開発者が Taobao データに HTTP リクエストを送信した後に発生する問題 (HTTP 接続エラー、プラットフォーム レベルのエラー、ビジネス レベルのエラーなど)。 3 種類のエラー問題は、淘宝サーバーへのアクセス、TOP アクセス プラットフォーム、淘宝バックエンド ビジネス サーバーの 3 つのレベルで発生します。
1. HTTP 接続エラーの問題:
タオバオ サーバーへのリクエスト中にエラーが発生します。このタイプのエラーは通常、HTTP 応答コードによってマークされます。HTTP 応答コードは次のとおりです。 3 桁の 10 進数。HTTP サーバーから送信される応答の最初の行に表示されます。応答コードには 5 種類あり、最初の桁で表されます。
1xx: 情報、要求を受信、処理は続行
2xx: 成功、アクションは正常に受け入れられ、理解され、採用されました
3xx:リダイレクト、リクエストを完了するために実行する必要があるさらなるアクション
4xx: クライアント エラー、リクエストに構文エラーが含まれているか、リクエストを実行できません
5xx: サーバー エラー、サーバーは明らかに無効なリクエストを実行できません
開発者が TOP サービスを呼び出すと、ほとんどの場合、200: http 要求成功、404: 要求されたサービスが見つかりません、500 内部サーバー エラーなどを受け取ります。開発者が受け取った応答コードが 404 の場合は、ユーザーのネットワークに問題があることを意味し、開発者が受け取った応答コードが 500 の場合は、ネットワークは正常だが上位サービスが応答できないことを意味します。
ローカル ネットワークに問題がある場合は、コマンド ライン ping gw.api.taobao.com を直接入力して、淘宝網サーバーへのリクエスト速度をテストできます。速度が非常に遅い場合は、速度を上げることを検討してください。 ping が失敗した場合は、ネットワーク管理者に問い合わせてください。サーバーが淘宝網のドメイン名をブロックしているかどうかを確認します。
2. プラットフォーム レベルのエラーの問題:
TOP にプラットフォームへのアクセスを要求するときにエラーが発生します。この時点で、TOP から返されるエラー コードは 100 未満です。このエラーは通常、ユーザーのリクエストがアクセス許可とセキュリティに準拠していません。トラフィック フローと最も基本的なパラメータの検証が原因です。
3. ビジネス レベルのエラー問題:
バックエンド ビジネス サーバーの問題をリクエストすると、返されるエラー コードは 500 ～ 1000 です。特定のサブエラー コードと解決策については、を参照してください。 API ドキュメントへ。
2. 詳細なトラブルシューティング フローチャート
上記の問題を発見した後の開発者の処理フローを詳しく説明します。 
#3. 簡単なトラブルシューティングの例
#例 1まず、トラブルシューティング プロセスに従って API の問題を特定し、次に API ドキュメントのエラー コード解決策を確認します:
1. ウィンドウを推奨する場合、ユーザーは合計金額を入力する必要があります。ウィンドウ推奨の量。一部のユーザーはさらに損失するため、ウィンドウ推奨が最大推奨数を超えているというエラーを報告します。ウィンドウの総数は毎日定期的に更新されます。ウィンドウの総数 = 残り推奨ウィンドウのウィンドウ (このエラーを完全に排除することはできません)
2. 開発者は最初に taovao.shop.remainshowcase.get インターフェイスを呼び出し、販売者の残りのショーケース数を取得し、論理的な判断を行ってから、ショーケースの推奨インターフェイス。
例 2
ローカル プログラムが接続リセット エラーを報告し、トップ エラー コードが返されません。この種の問題を解決するにはどうすればよいですか?
提案:
1. タスクを合理的に削減し、タスクの粒度を減らし、トランザクション時間を短縮し、トランザクション実行の成功率を向上させ、ロールバック コストを削減します;
2. 繰り返されるコンテンツをマージします。タスク内で、許容される時間間隔内で繰り返される可能性のある操作を減らします;
3. 単一ループ呼び出しの数を減らすためのバッチ操作インターフェイスがあるかどうかを確認します;
4. の数を制御します。ワーカー スレッド プール内のスレッドを増やし、実際のパフォーマンスと他のサーバーの処理能力に応じて並列タスクの数を設定します。
同時に開発されるスレッドの数が増えるほど、成功率が高くなるわけではありません。
まず第一に、ローカル リソースは限られています (オープンされるスレッドが増えるほど、ローカル GC リサイクルの頻度が高くなり、実行速度に影響し、効率が低下します)。
第二に、IP 接続が多すぎるため、相手が接続を積極的に拒否する可能性があります; (DOS 保護) 繰り返しますが、チャネルは再利用できません。 (現在の 1.6 JDK バージョンでは、TCP チャネルをより適切に再利用できるようになりました。多数の TCP チャネルを同時に瞬時に開くこと自体が損失です。場合によっては、部分的なシリアル化により、TCP チャネルの数がある程度削減され、チャネルが合理的に使用されます。効率と成功率を向上させるには、クライアントがフロー制御を行うことも重要です)例 3
ネットワーク パケットの解決策損失問題:
問題の背景:1. インターネットの物理回線の信頼性は 100% ではないため、ISV サーバーと TOP## 間の通信でデータ損失が発生します。 #2. 開発者は、各アクセス中に取得したデータが完全であるかどうか、パケット損失がないかどうかを検証する方法が必要です
3. 現在、一部の ISV は整合性を検証するためにこの方法を使用しています: API を連続して複数回呼び出し、返された結果を比較します。それらがまったく同じであれば、完全であるとみなされます。この方法は信頼性が低く (複数の呼び出しで異なるビジネス結果が返される可能性があります)、ISV の開発コストが増加し、TOP のサーバーへのプレッシャーも増加します
解決策:
ISV に関する開発者のフィードバックに応じて解決するには検証データの整合性の問題に対処するため、TOP は HTTP ヘッダーに新しい要素、top-bodylength を追加しました。
使用方法: 開発者は、この top-bodylength の値を取得し、受信した HTTP ボディの長さを計算します。この 2 つが等しい場合、返されたデータが完全であることを意味します。HTTP ボディの長さの場合、が計算され、値が top-bodylength より小さい場合は、パケット損失が発生したことを示します。
注:
1: TOP は HTTP ボディを変更しないため、既存のアプリケーションには影響しません。
2: top-bodylength は、HTTP ボディを表す String 文字の長さです (中国語と英語は両方とも 1 つの長さとしてカウントされます)
2. エラー コードのリスト
#1. 現在、開発者が API を呼び出すときに発生する可能性のあるエラーには、API プラットフォーム エラー、ISV ビジネス エラー、コンテナ エラーの 3 種類があります。以下は、ISV の成功率に関連する名詞の紹介です:
有効な訪問 = 成功した訪問 ISV ビジネス エラー (成功した訪問とは、データが正常に取得され、エラーが報告されないコールを指します)
ISV 成功率 = 成功した訪問数/効果的な訪問数
2. タオバオ サーバーへの接続エラーは、主に http 接続エラーまたは接続の再設定です。このタイプのエラーは、開発者がタオバオ サーバーにアクセスすることが原因で発生する問題です。サーバー管理者に直接問い合わせるか、インターネットで回答を検索してください。
#1. API プラットフォーム エラー
API プラットフォーム エラーには主に 2 種類のエラーが含まれます:
(1) エラー コード 100 未満の呼び出しエラー (エラー コード 15、40、および 41 を除く) このエラーは通常、ユーザーの要求がさまざまな基本チェックに準拠していないために発生します。これらのエラーが発生した場合、ユーザーはまずアプリケーションの権限や頻度などを確認し、次にドキュメントを参照して受信パラメータが完全で正当であるかどうかを確認します。
(2) サブエラー コード (sub_code) は、「isp.」で始まる呼び出しエラーであり、通常、このエラーはサーバー側の例外によって発生します。このタイプのエラーが発生したユーザーは、問題を解決するために一定の時間が経過した後に再試行する必要があります。
エラー コード 100 未満のプラットフォーム レベルのエラー| エラー コード エラーの説明 - 英語のエラー説明 - 中国語の解決策 3Upload Fail 画像のアップロードに失敗しました。受信画像形式を正しい形式と適切なサイズに変更してください。メッセージ本文を入力し、それでも送信できない場合は、画像サイズを小さくするか、ネットワーク帯域幅を増やして試してください 7App Call Limited API を適切に呼び出すための頻度制限調整プログラムの呼び出しなど、アプリケーションの呼び出し数が制限を超えています。回数制限時間が経過するまで再度発信しないと、Taokeの発信回数は前月の取引量に応じてシステムにより自動的に変更され、変更後の回数は公式フォーラムホームページで告知の形で通知されます開発者自身が確認できる 9Http Action Not allowedHTTP メソッドは禁止されている POST または大文字を使用してください GET、画像やその他の情報が入ってくる場合は POST を使用する必要があります 10Service currently Unavailable サービスが利用できない原因は主に不明な例外です渡されたパラメータがドキュメントの説明に準拠しているかどうかを慎重に確認してください 11ISV 権限が不十分です開発者権限サブエラー コードが不十分です 現在、isv.permission-api-package-empty はどのアクセス パッケージにも関連付けられていません。対応するアクセス パッケージを申請することをお勧めします。ビジネス ルールに従ったアクセス許可 isv.permission-api-package-not-allowed は、アクセスできないグループの API へのアクセスを許可しません。自分で確認することをお勧めします。適用されたアプリケーション タグは正しいですか? 本当にアクセスする必要がある場合は、アクセス不可グループの API を使用するには、ビジネス ルールに従って、対応するビジネス ラインから権限を申請する必要があります。例: バイヤーアクセス不可グループには、バイヤー アプリケーションが isv.permission にアクセスすることを許可しないいくつかの注文 API が存在します。 - api-package-limitに関連付けられたパッケージではAPIへのアクセスは許可されていません。ビジネスルールに従って、対応する権限isv.permission-ip-whitelist-limitを申請することを推奨します。IP制限によりアクセスは許可されません。セキュリティ センターで正しい IP ホワイトリスト isv を構成することをお勧めします。permission-api-widget-only-limit ではウィジェット (コンポーネント) へのアクセスのみが許可されます。12ユーザー権限が不十分です。ユーザー権限が不十分です。アプリケーションには、値のインターフェイスを呼び出す権限がありません。 -追加されたアクセス許可。タオバオ パートナー バックエンドでアクセス許可アプリケーションを送信できます。 13不十分なパートナー アクセス許可 不十分なパートナー アクセス許可 アプリケーションには、付加価値アクセス許可のインターフェイスを呼び出すアクセス許可がありません。淘宝パートナー バックエンドでアクセス許可アプリケーションを送信できます。 21 不足しているメソッドは次のとおりです。メソッド名パラメータがありません。受信パラメータがメソッド フィールドに追加されます。 22 無効なメソッド メソッド名が存在しません。受信メソッド フィールドは、呼び出している API の名前である必要があります。API は存在します。 23無効 形式が無効ですデータ形式 渡される形式は、json または xml のいずれかである必要があります。 24Missing Signature 署名パラメータが欠落しています。 受信パラメータには、sign フィールドが含まれている必要があります。 25Invalid Signature 無効な署名 署名は、正しいアルゴリズムに基づいて計算する必要があります。アルゴリズムについては、次を参照してください: //open.taabao.com/doc/detail.htm?id=101617#ss226Missing Session is missing the SessionKey パラメーター. 渡されたパラメーターにはセッション フィールドが含まれている必要があります。27無効なセッション、unmix-sessionkey -failure 無効な SessionKey パラメータが渡されました。セッションは、ユーザーがセッションをバインドすることによって取得する必要があります。報告されたセッションが不正な場合は、ユーザーがセッションをバインドしていないか、セッションの有効期限が切れていることが原因である可能性があります。ユーザーは再バインドする必要があります新しい sessionKey を渡しますKey28Missing App Key に渡された AppKey パラメータがありません パラメータには app_key フィールドが含まれている必要があります 29Invalid App Key Invalid AppKey パラメータ アプリケーションが配置されている環境は、選択した環境と一致しません。例: アプリケーションは次のようになります。サンドボックス テスト環境ですが、公式環境でテストすることを選択します。 30Missing Timestamp にはタイムスタンプ パラメータがありません。渡されたパラメータにはタイムスタンプ パラメータが含まれている必要があります。31Invalid Timestamp は不正なタイムスタンプ パラメータのタイムスタンプです。形式は yyyy-mm-dd hh:mm:ss です。例: 2008-01-25 20 ：23：30。タオバオ API サーバーでは、クライアントは 10 分の時間エラーをリクエストできます。 32 バージョンがありません。バージョン パラメータがありません。受信パラメータには v フィールドが含まれている必要があります。 33 無効なバージョン。バージョン パラメータが不正です。ユーザーが渡したバージョン番号は次のとおりです。不正な形式であり、数値形式である必要があります。 34 Unsupported バージョンはサポートされていません。ユーザーによって渡されたバージョン番号が提供されていません。 42 セッション権限が不十分です。短い認証権限が不十分です。高リスク API が呼び出されています。参照してください。セキュリティ レベルのドキュメント //open.taabao.com/doc/detail.htm?id=100243 パラメーター エラー。通常、ユーザーが渡した不正なパラメーターが原因です。入力パラメーターの形式と範囲が一致しているかどうかを注意深く確認してください。 1 対 1 への 44無効なアクセス トークン。無効なアクセス トークンは、通常、ユーザーがトップ プロトコルを使用して取得したセッション キーであり、API を呼び出すか、https 経由で環境を呼び出すためのアクセス トークンとして使用されます。エラー 47 無効なエンコード エンコード エラーは通常、 http リクエストを行うときにユーザーが UTF-8 エンコーディングを使用していないことが原因です |
##プラットフォーム レベルのサブエラー
