序文
実際の作業では、プロジェクトでサードパーティの API インターフェイスを呼び出してデータを取得したり、データ交換や通信のためにデータをレポートしたりする必要があることがよくあります。
では、サードパーティの API インターフェイスを呼び出すときにどのような問題が発生するのでしょうか? これらの問題を解決するには？
この記事では、サードパーティ API インターフェイスのトピックについて説明します。お役に立てば幸いです。
1 ドメイン名にアクセスできません
一般に、サードパーティ プラットフォームの API インターフェイスに初めて接続するときは、最初にブラウザまたは郵便配達員を介して呼び出し、インターフェイスにアクセスできるかどうかを確認します。
一気に何度もそう感じる人もいるかもしれません。
実際にはありません。
サードパーティ プラットフォームの API インターフェイスを呼び出したときに、そのインターフェイスが実際にダウンしていて、サードパーティはまだそれを認識していない可能性があります。
もう 1 つの最も重要な状況は、職場のネットワークがこの外部ネットワークのインターフェイスにアクセスできるかどうかです。
企業によっては、セキュリティ上の理由から、イントラネットの開発環境にファイアウォールを設定したり、その他の制限を設けたり、特定の外部ネットワーク インターフェイスにのみアクセスできる IP ホワイトリストがあります。
訪問したドメイン名が開発環境でアクセスできない場合は、運用保守同級生に追加してもらう必要がありますip白名单。
2 署名エラー
多くのサードパーティ API インターフェイスは通常、デジタル署名 (署名) 検証を追加して、他人によるデータの改ざんを防ぎます。
sign = md5(複数パラメータ連結+キー)
サードパーティ プラットフォーム インターフェイスに初めて接続するときに、パラメーター エラーや署名エラーなどの問題が発生します。
その中で、パラメータエラーは解決しやすく、署名エラーの問題に焦点が当てられています。
署名は、何らかのアルゴリズムによって生成されます。
例: パラメータ名とパラメータ値をコロンで連結し、複数のパラメータがある場合は最初の文字で並べ替え、複数のパラメータを連結します。次に、salt (キー) を追加し、md5 を渡して署名を生成します。
複数のパラメーターがあり、それらをアルファベットの逆順に並べると、最終的に生成される署名に問題が生じます。
開発環境のキーを使用し、本番環境のキーを使用すると、本番の署名にも問題が発生する可能性があります。
サードパーティのプラットフォームが最新の 3 つの md5 世代の署名を必要としているのに、1 回しか使用していない場合、生成された署名でも問題が発生する可能性があります。
したがって、インターフェースが共同でデバッグされる場合、インターフェースの署名はより厄介です。
サードパーティのプラットフォームが署名を生成するための SDK を提供するのが最善ですが、そうでない場合は、そのドキュメントに従って署名アルゴリズムを手書きするしかありません。
3 署名の有効期限が切れています
上記の手順で署名を調整し、通常はサードパーティのプラットフォームにアクセスしてデータを取得できます。
ただし、同じ要求に対して、15 分後にデータを再度取得しても、返されないことがあります。
サードパーティ プラットフォームがインターフェイスを設計するとき、タイムスタンプ検証が署名に追加され、同じリクエストが 15 分以内にデータを返すことが許可されます。15 分を超えると、そのまま失敗を返します。
この設計は、安全性を考慮したものです。
誰かが力ずくでクラックするためのツールを使用したり、絶えず署名を偽造したり、インターフェース検証を絶えず呼び出したりするのを防ぐために、徹底的に取り組めば、いつか検証に合格することができます。
記号 = md5 (複数のパラメーターの連結 + キー + タイムスタンプ)
したがって、タイムスタンプのチェックサムを増やす必要があります。
これが発生した場合は、パニックにならず、新しいリクエストを再開してください。
4 インターフェイスが突然データを返さない
サードパーティ プラットフォームの API インターフェイスを呼び出してデータをクエリすると、データは常に最初に返されます。
しかし、ある日突然、データが返されませんでした。
ただし、API インターフェイスは正常に応答できます。
驚かないでください。データを削除したサードパーティのプラットフォームが存在する可能性があります。
サードパーティ プラットフォームの API インターフェイスをドッキングした後、テスト環境にデプロイしたところ、ある日、テスト環境のすべてのデータが削除されたため、インターフェイスがデータを返さないことがわかりました。
したがって、テスト環境をデプロイする前に、最初に相手と通信する必要があり、テストに使用するデータは削除できません。
5 トークンの無効化
一部のプラットフォームの API インターフェースは、要求を行う前に、別の API インターフェースを呼び出してトークンを取得し、ヘッダーでトークン情報を保持して他のビジネス API インターフェースにアクセスする必要があります。
トークンを取得するための API インターフェイスでは、アカウント番号、パスワード、キーなどの情報を渡す必要があります。この情報は、インターフェイス ドッキング パーティごとに異なります。
他の API インターフェースをリクエストする前に、毎回トークンを取得するためのインターフェースをリアルタイムで呼び出してトークンを取得しますか? または、トークンを一度リクエストして、それを redis にキャッシュし、後で redis から直接データを取得しますか?
他の API インターフェイスを要求する前に、インターフェイスを呼び出してリアルタイムで 1 回トークンを取得すると、インターフェイスは毎回 2 回要求され、パフォーマンスに影響を与えるため、明らかに後者の傾向があります。
要求されたトークンが redis に保存される場合、別の問題があります:token失效問題。
サードパーティ プラットフォームを呼び出してトークン インターフェイスを取得することによって取得されたトークンには、通常、1 日、1 か月などの有効期間があります。
有効期間中は、API インターフェースに通常どおりアクセスできます。トークンの有効期限を過ぎた場合、API インターフェイスはアクセスを許可しません。
redisの有効期限をトークンの有効期限と同じにすればいいじゃないですか。
アイデアは良いのですが、問題があります。
システムのサーバー時間がサードパーティのプラットフォームのサーバー時間とまったく同じであることをどのように保証できますか?
以前、トークンを取得するためのインターフェイスを提供し、30 日以内にリクエストを開始して、毎回同じトークン値を返す大規模なファクトリに遭遇したことがあります。30 日以上経過している場合は、新しいものが返されます。
これが発生する可能性があります。システムのサーバー時間は速くなり、サードパーティ プラットフォームの時間は遅くなるはずです。その結果、30 日後、システムはサードパーティ プラットフォームのトークン取得インターフェイスを呼び出してトークンまたは古いトークンを取得し、redis に更新しました。
しばらくするとトークンの有効期限が切れ、システムはまだ古いトークンを使用してサードパーティ プラットフォームの他の API インターフェイスにアクセスし、常に失敗を返します。しかし、新しいトークンを取得するには 30 日かかり、長すぎます。
この問題を解決するには、トークン無効化の例外をキャッチする必要があります。他の API インターフェイスを呼び出すときにトークンが無効であることがわかった場合は、すぐにトークン インターフェイスを要求し、新しいトークンをすぐに redis に更新します。
これにより、トークンの無効化の問題を基本的に解決でき、他のインターフェースへのアクセスの安定性とパフォーマンスを可能な限り確保できます。
6 インターフェースのタイムアウト
システムがオンラインになった後、サードパーティの API インターフェイスを呼び出すときに発生する可能性が最も高い問題は、接口超时問題になるはずです。
システムと外部システムの間には非常に複雑なリンクがあり、途中で多くの問題が発生し、API インターフェイスの対応時間に影響を与える可能性があります。
API インターフェイスの呼び出し元として、サードパーティ API インターフェイスのタイムアウトの問題に直面した場合、問題に関するフィードバックを提供し、インターフェイスのパフォーマンスを最適化することに加えて、より効果的な方法は、インターフェイスの呼び出しを増やすことです失败重试机制。
例えば：
int retryCount=0;
do {
try {
doPost();
break;
} catch(Exception e) {
log.warn("接口调用失败")
retryCount++;
}
} where (retryCount <= 3)インターフェイス呼び出しが失敗した場合、プログラムは自動的にすぐに再試行します3次。
再試行後に成功すると、API インターフェイスが呼び出されます成功。
3 回再試行しても失敗する場合は、API インターフェイスを呼び出します失败。
7 インターフェイスは 500 を返します
時折、サードパーティ API インターフェースを呼び出す際に異なるパラメーターが原因で 500 の問題が発生することがあります。
例: 一部の API インターフェースはパラメーターを適切にチェックせず、少数の必須フィールドは検証なしで空にすることはできません。
一部のシステム リクエストでは、特定のパラメータを介して API インターフェイスを呼び出すときに、そのパラメータが渡されない場合、相手側で NPE の問題が発生する可能性があります。そして、このインターフェースの戻りコードはおそらく 500 です。
別の状況としては、API インターフェースに内部バグがあり、異なるパラメーターが渡され、異なる条件分岐ロジックが取られる. 特定の分岐が取られると、インターフェース ロジックが異常になり、インターフェースが 500 を返す可能性があります.
この場合、インターフェイスを再試行しても意味がありません. サードパーティの API インターフェイス プロバイダーに連絡して、関連する問題を報告し、特定の理由を調査するよう依頼することしかできません.
問題を解決するために、バグを修正したり、データを修正したりすることがあります。
8 インターフェイスは 404 を返します
呼び出されたサードパーティの API インターフェイスが 404 を返すことをシステム ログで確認できた場合は、非常に残念です。
サードパーティの API インターフェイスがオンラインでない場合は、インターフェイスの名前が変更され、通知が間に合わなかった可能性があります。
この場合、ハンマーで叩くことができます。
もう 1 つの状況は、サードパーティの API インターフェイスが既にオンラインである場合、最初にインターフェイスを正常に呼び出すことができるということです。
サード パーティはインターフェイス アドレスを変更していません。
その後、ある日突然、サードパーティの API インターフェイスを呼び出すときに 404 問題がまだ発生していることに気付きました。
この場合、ゲートウェイに問題があるか、最新の構成が有効になっていないか、ゲートウェイ構成の変更が問題の原因である可能性があります。
一言で言えば、ピット。
9 インターフェースが返すデータが少ない
以前はサードパーティの API インターフェースを使用してページ内のデータをクエリしていましたが、アクセスは非常にスムーズでしたが、オンラインにすると、インターフェースにデータが不足していることがわかりました。
原因を確認したところ、ページング クエリ インターフェイスが总页数実際よりも少ない誤った結果を返したことがわかりました。
一部の友人は好奇心旺盛かもしれませんが、どうやってこのような奇妙な問題を発見したのでしょうか?
サードパーティ API インターフェイスを呼び出してページ内の分類データを照会する前に、サードパーティ分類テーブルにデータを保存してください。
ある日突然、カテゴリ ツリーにサード パーティのカテゴリが見つからないと報告されました。
確認したところ、実際には存在しないことがわかりました。
サードパーティ API インターフェースの呼び出しの応答ログから、このカテゴリのデータは見つかりませんでした。
この API インターフェースはページ単位のクエリ インターフェースであり、現在、クエリ データは 10 以上のページに分割されていますが、目的のカテゴリはまだ見つかりません。
以前のアプローチでは、API インターフェースによって照会されたデータを一度呼び出し第一页、同時に調べていました总页数。次に、総ページ数に基づいてループで呼び出して、其他页データをクエリします。
その時点で、インターフェースから返されるページの総数に問題があるのではないかと推測しました。
したがって、インターフェイス呼び出しロジックは次のように変更できます。
最初のページから開始して、データを確認するために API インターフェイスが呼び出されるたびに、ページ数が 1 ずつ増加します。次に、インターフェイスから返されたデータが pageSize より小さいかどうかを判断し、
未満でない場合、次の呼び出しが行われます。
より小さい場合は、それが最後のページであることを意味し、後続の呼び出しを停止できます。
検証の結果、そのカテゴリのデータはこの方法で取得できることがわかりました。これは、サードパーティのページング クエリ インターフェイスによって返されたページの総数が実際の状況よりも少ないことを示しているだけです。
10 ひそかに変更されたパラメーター
以前、インディケータのステータスを取得するために特定のプラットフォームの API インターフェイスを呼び出しました. 両者間の以前の合意によると、ステータスには と の 2 種類があり正常ます禁用。
次に、ステータスをメトリクス テーブルに更新します。
その後、両当事者のシステムがオンラインになり、数か月間稼働しました。
ある日突然、ユーザーはデータの一部が明らかに削除されたと報告しました。
この時、当方で指標表を確認したところ正常な状態でした。
次に、プラットフォームを呼び出すための API インターフェイス ログを確認し、インジケーターの返されたステータスが次のようになっていることを確認します下架。
何？
これは何の状態ですか？
プラットフォームの開発者と連絡を取った後、彼らがステータスの列挙を変更し、複数の値を追加しました: オンシェルフ、オフシェルフなど、そして私たちに通知しなかった.
これが落とし穴です。
ここのコードから判断すると、状態が無効になっていない場合は、通常の状態と見なされます。
在庫切れ状態を正常状態と自動判定します。
相手方に連絡したところ、在庫状況が異常であり、インジケーターが表示されないことを確認した。彼らはデータを変更し、一時的にこの指標の問題を解決しました。
その後、インターフェースのドキュメントに従って、列挙値を以前の状態に戻しました。
11 インターフェースは行き当たりばったり
サードパーティのインターフェースを呼び出すときに、インターフェースが良いか悪いかという状況に遭遇したことがあるかどうかはわかりません。
5 分前、インターフェイスは正常にデータを返すことができました。
5 分後、インターフェースは 503 Unavailable を返します。
さらに数分後、インターフェイスは再び正常にデータを返すことができます。
この場合、サードパーティのプラットフォームがサービスを再起動している可能性が高く、再起動プロセスの間、サービスが一時的に利用できなくなる可能性があります。
別の状況があります。複数のサービス ノードがサードパーティ インターフェイスにデプロイされており、一部のサービス ノードがダウンしています。また、サードパーティのインターフェースを要求する際の戻り値の良し悪しにもつながります。
さらに、別の状況があります。ゲートウェイの構成が時間内に更新されず、オフライン サービスが削除されません。
このように、ユーザー要求がゲートウェイを通過すると、ゲートウェイはその要求をオフライン サービスに転送し、サービスを利用できなくします。ゲートウェイは要求を通常のサービスに転送し、通常のサービスが返されます。
この問題が発生した場合は、できるだけ早くサードパーティ プラットフォームに問題を報告し、インターフェイス エラーの再試行メカニズムを追加する必要があります。
12 ドキュメンテーションとインターフェイス ロジックの間の矛盾
以前、サードパーティのプラットフォームが提供する API クエリ インターフェースにも遭遇しましたが、インターフェース ドキュメントには、フィールドdr表現があることが明確に記載されていました删除状态。
このフィールドを使用すると、サードパーティのプラットフォームの機密データを同期すると、どのデータが削除されたかを知ることができ、関連するデータを削除するのに間に合うようにデータを調整できます。
後で、いくつかのカテゴリが彼らの側では削除されたが、私たちの側では削除されていないことがわかりました.
どのような状況ですか？
コードのロジックは非常に単純です. コードを確認したところ、バグは見つかりませんでした. なぜこれが起こるのですか?
ログを追跡したところ、サードパーティのプラットフォームが分類インターフェイスを取得するために呼び出されたときに、相手方が削除された分類データを返してくれなかったことがわかりました。
つまり、インターフェイス ドキュメントの dr フィールドは役に立たず、インターフェイス ドキュメントはインターフェイス ロジックと矛盾しています。
多くの友人がこの問題に遭遇したと推定されます。
この問題を解決したい場合、主な解決策は 2 つあります。
サードパーティ プラットフォームは、ドキュメントに従ってインターフェイス ロジックを変更し、削除されたステータスを返します。
カテゴリ クエリ インターフェイスを呼び出した後、システムはカテゴリ コードに従って判断し、データベース内の一部のカテゴリのコードがインターフェイスの戻り値にない場合、これらのカテゴリを削除します。
延滞13件
Baiduの請求書識別インターフェースを呼び出しました。これにより、請求書情報を自動的に識別し、請求書番号や金額などの情報を取得できます。
以前は別の同僚が接続していたインターフェースでしたが、彼は後に去りました。
請求書認識機能が立ち上がり、問題なく長く使用できています。
その後、ある日、本番環境のユーザーから請求書を認識できないという報告がありました。
関連するサービスのログを確認したところ、異常は見られませんでした。
コードを開いてよく見てみると、同僚のコードがサードパーティ API インターフェイスを呼び出していることがわかりました.応答データを受信すると、それは直接オブジェクトに変換され、そのときに返された文字列は出力されませんでした.
インターフェイスの戻り値に問題があるのではないでしょうか?
その後、ログを追加し、インターフェイスの実際の戻り値を出力しました。
原因が判明し、延滞であることが判明しました。
例外があるとすれば、Baidu の API インターフェイスによって返されるデータ構造は、以前の同僚のエンティティの一部のパラメーターでは取得できません。
これは小さな穴ではありません。
When we receive the data returned by the third-party API interface, we try our best to use the string to receive the return value first, and then convert the string into the対応するエンティティ クラス. 戻り値をログに出力する必要があります後で問題の位置付けを容易にします。
Do not directly use the entity object to receive the return value. 一部の API インターフェイスでは、異なる例外が発生した場合、返されるデータ構造がまったく異なります。
ゲートウェイ システムから直接返される異常な結果もあれば、ビジネス システムから返される異常な結果もあります。
実際、分類ツリーのクエリ インターフェイスを呼び出すなど、以前にも別の落とし穴に遭遇したことがありますが、サード パーティから返されたデータには重複した ID が含まれています。
データを取得するために、ジョブ内でサードパーティ API インターフェースを周期的に呼び出します.呼び出しの 1 つが失敗した場合、それは try/catch で例外をキャッチしますか? 後続の呼び出しを続行しますか、それとも現在のプログラムを直接終了しますか? データの一貫性を確保する方法を試してみてください。現在のプログラムを終了し、後続のプロセスをどのように処理しますか?