gentarok / zaifapiwrapper Goto Github PK

ドキュメントのバージョンが上がってないが、いくつかの機能追加があったみたいなので対応する。

×Extention
○Extension

各APIの返すJsonのデータには、ある程度共通しているものがある。
（PublicとFutureのLastPrice等。もしストリーミングに対応するならもっと。）

APIの戻り値については、こちらがコントロールできず、いつどんな変更が行われるか予測できないので全て個別の型にしていた。

でも、常識的には項目の追加はあっても削除・変更はあまり考えられないので、共通するデータを統一的に扱いたいケースは普通にありそう。

今のように分けるにしても、せめて同一の型からの派生型にしておいた方が良かったかも。
やるとしたらv2.0.0にしよう。

DatetimeとUnixTimeの変換に拡張メソッドを用意していたが、DateTimeOffsetクラスにToUnixTimeMilliseconds ()やFromUnixTimeMilliseconds ()が用意されているので、標準のものを使おう。

Zaif.sln -> ZaifApiWrapper.sln
にしたい

SampleWinFormは別リポジトリに移動したい

ApiClient.PostAsync()メソッド実行時にループを例外で脱出した場合、その後のAPI呼び出しで「nonce not incremented」が返される現象を確認

timestamp_closedがSnake Caseになってる

負荷が高いと
「trade temporarily unavailable」
がよく出るようなので、こいつが出たら既定でリトライしたい

速いらしい。
https://github.com/neuecc/Utf8Json
現状パフォーマンスがボトルネックになってると思わないが、速度計測してみて良さそうなら乗り換えてもいいかも。

System.Reflection.TargetInvocationException: 呼び出しのターゲットが例外をスローしました。 ---> System.Collections.Generic.KeyNotFoundException: 指定されたキーはディレクトリ内に存在しませんでした。
場所 System.Collections.Generic.Dictionary2.get_Item(TKey key) 場所 ZaifApiWrapper.LeverageApi.CreatePositionAsync(IDictionary2 parameters, CancellationToken token)
場所 ZaifApiWrapper.LeverageApi.CreatePositionAsync(String type, String currencyPair, String action, Decimal amount, Decimal price, Decimal leverage, Nullable1 groupId, Nullable1 limit, Nullable`1 stop, CancellationToken token)
--- 内部例外スタック トレースの終わり ---
場所 System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
場所 System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
場所 System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
場所 SampleWinForm.Form1.<buttonExecute_Click>d__6.MoveNext() 場所 D:\Repos\GitHub\gentarok\ZaifApiWrapper\SampleWinForm\SampleWinForm\Form1.cs:行 60

考慮漏れというか何というか。
staticメンバに初期化で持たせた値をインクリメントしてるので、アプリをまたぐと防ぎようがない。

基本的には１アプリ１APIキーが理想なので制限にしてしまっても良さそう。
ただ、開発用のキーとかでコレが出るのは困るかもしれない。

実行直前に時間ベースでnonceを生成する方が良いかも。
精度の問題もあるので厳密な意味では同一かそれ以下を値を使ってしまう可能性があるけど、リトライのフローに流すことである程度は表面化しにくくなるはず。

内部的にリトライする際に処理を行うためのActionを引数に取るオーバーロードを用意する？
（進捗状況を知る意味でもあったほうが良さそう）

現在は「please try later」という文字列が含まれるかどうかで判断しているが、どのようなメッセージが返されるか予測できないため、外部から正規表現パターンとして指定可能としたい。

（ApiClientOptionへのプロパティの追加とApiTimeoutRetryIntervalのプロパティ名の破壊的変更が必要だけど）

拡張性や保守性を高めるため、各APIクラスとHTTPの通信を行う内部コアロジックの部分はアセンブリを分割しても良いかもしれない（通信部分だけ使いまわしたいケースがあった）

先物のデータだけ「FutureResponce」ってフォルダ名になってる
名前空間はFutureData
他は全てxxxDataなので、先物だけ変え忘れてたっぽい