1

API エラー条件を巧みに処理する取引アプリケーションを開発している間、私は現在、使用制限に関する API エラーのクラスに焦点を当てています。

Trading APIのエラー リストは、私には広すぎます。リストによると、次のエラー コードがあります。

  • エラー 518: アプリケーションがこの呼び出しで使用制限を超えました [...]
  • エラー 18000: 1 日のリクエスト制限を超えたため、その日の残りの時間は追加のリクエストを行うことができません。
  • エラー 218050: このアプリケーションのユーザーは、1 日、1 時間、および 6 分間に発信できる通話数に制限されています。[...]
  • エラー 21919144: 最大通話制限を超えました
  • エラー 21919165: 最大通話制限を超えました。

これらのエラーのうち、すべてではないにしても、どのエラーをアプリケーションが自動的に処理する必要があるかを確認したいと考えています。エラー コード番号が大きいほど統合が不十分になり、将来の API バージョンで意味が変わる可能性が高くなるのではないかと特に心配しています。

考慮に値するのは、上にリンクされている Trading API エラー リストは、エラーの意味を文脈化していないため、関連するテキストの説明が誤解を招く可能性があることです。

4

1 に答える 1

2

私の推測では、それらをすべて自動的に処理します。

エラー コードの変更が気になる場合は、その可能性は低いと思います。彼らはむしろ別のエラーコードを作成し、そこにあるすべてのアプリを壊したり、変更を強制したりします。

また、比較するエラーメッセージもあります。一致しない場合は、無視するか、フォールバック ハンドル ルーチンを使用できます。

最後に、古いバージョンに戻って読み取り、エラー コードのログを変更することができます。これらのエラーを再定義する頻度がわかります。

于 2013-10-07T05:03:50.807 に答える