立花証券のAPIの仕様をみていく
完璧に便利なAPIではないんですよね。
ってことで、立花証券のAPIもみていく。
サービス
まず立花証券のAPIサービスは、e支店の口座を持っていることが前提になる。
次に、APIで取引可能な対象の商品は、国内株式の現物・信用のみ。
先物やオプション、米国株などには対応していない。
そして利用は無料！！！
ついでに立花証券e支店の取引手数料・諸経費は他証券会社に比べてかなり安めだと思う。
信用取引であれば取引手数料が無料で、信用金利は1.6%、管理費なども無料。
正直かなり強いと思う。メインの証券口座にしてもいいレベル。
サンプル
pythonでかかれたコードがサンプルとして公開されている。
ちょっとクセありな仕様
ぱっとドキュメントみただけやけど、かなり癖のある仕様っぽい。
GETのクエリパラメータにJSONをくっつける
JSONリクエストとして多いパターンは、POSTのBODYにJSON形式の文字列を入れるものやと思う。
けど、このAPIではGETのクエリにJSONをつける。
どうなるかというと
https://example.com/auth/?{"p_no":"1","p_sd_date":"2020.07.01-10:00:00.000","sCLMID":"CLMAuthLoginRequest","sUserId":"login-id","sPassword":"pswd"}
みたいなリクエストになる。
もちろん、: とかURLとして特別な意味を持つ文字はエンコードしてあげないといけない。
見慣れへんよなぁ。
リクエストに通し番号を付けなくてはいけない
上のURL例でもあるけど、 p_no というのがある。
これはどのリクエストにも必要な番号なんやけど、これが最新のリクエストより1以上大きくないとエラーになる。
同じリクエストを複数回送らないためには安全ではあるけど、加算し忘れたり逆転したりするとそのあとのリクエストが全滅する可能性もある。
単純に加算していけばいい。というので間違いはないけど、
リクエスト毎に薄いながらも依存が発生することに問題がある。
それぞれのリクエストは独立して送信されるべきやと思うけど、
同じ番号を踏まないように、送信順が逆にならないように、非同期処理の中でも同期的に直列で処理しなくてはいけない。
これが昨今の並列処理にどれだけ悪影響を与える仕様かははっきりしてる。
日本語がShiftJISで扱われる
UTF-8がスタンダードな文字コードになっているにもかからず、SJISで扱う必要がある。
UTF-8とShiftJISで記号とかの文字コードがどう違うか把握してないけど、日本語だけはShiftJISにしなくてはいけないことは確定してるっぽい。
読み込むにも、書き込むにも手間が増える。
マスタ情報はリクエストのレスポンスでは情報を得られない
マスタ系のAPIは、リクエストに対してのレスポンスでは情報を得られず、
別途処理されてダウンロード通知をうける形になるっぽい。
欲しいときに欲しい情報を得られるというわけじゃなさそう。
仮想URLへのリクエスト
認証だけは共通のホストに対してリクエストすることになるが、
それ以外のリクエストに関しては、認証時に発行された仮想URLへのリクエストになる。
この仮想URLは同時に有効になるのは1つだけで多重での認証が許容されていない。
つまり、複数のツールを同時に動かすことができない。
ここまでの仕様を読んで、kabusapiより優位かと言われれば微妙。
kabusapiに関しては並列でのリクエストが可能なのに対し、
こちらは一問一答を利用側に求めているので、複数の処理が同時に飛ぶことを防がないといけない。
これはかなり重たい制約と言える。
jsonのキーが数値
ドキュメントをみると、 sUserId や、 sPassword といったキーが書かれているけれど、
実際に送信するキーは 690 や、 531 にする必要がある。
このマッピングがどこに書かれているかというと、
ここに配列があって変換する処理がある。
javascriptで書かれているものなので、他のプログラミング言語で使いたいなら書き換えるなどが必要やけど、
それ以前に、静的型付け言語だったりだと動的にjsonのキーを変えれないケースも少なくない。
ってことで、構造体に数値のキーを設定してあげないといけない。
長期的にみてこのキーの数値が変わることがあるのかが不安の種。
いまはV2R4というバージョンで、この番号が割り当てられているけど、
後日R5とかV3になったりしたときに、番号がずれるなどあったら保守が大変になりそう。
追記 これはオプション項目で変更することができた。
リクエストに sJsonOfmt という項目を追加し、ここに4を設定すれば項目キーのまま利用することができる。
また、この項目に1を追加すれば読める形で返してもらうこともできる。
4と1の両方をセットするには 1 | 4 でいいので、5を設定すればOK。
利用可能時間
APIの利用可能時間は、06:00 - 23:55 (たぶん)。
何がネックかっていうと、深夜に開発しよーとしても、情報が取れなかったりして困るって感じ。
基本的には日中に開発作業をする必要がある。
また、休日だと「只今、一時的にこの業務はご利用できません。」と出ることもある。
基本的にはザラバ中に開発・テストするのがよさそう。
空配列の代わりに空文字が返される
配列を返すような要素であっても、配列が空の場合は空文字が返されることがある。
つまり、配列を期待したところに、配列か文字列が返されるということになる。
注文一覧では配列で注文の情報が返される。
注文がある場合は {"55":[{注文の内容1},{注文の内容2}] という感じ。
が、注文がなければ、 {"55":""} となる。
このため、jsonから構造体にUnmarshalする前に、 "55":"" は "55":[] と置換するなどのひと手間が必要になる。
マスタデータダウンロードの初期ダウンロード完了レスポンスが遅い
マスタデータの取得の大半はchunked responseで受け取る必要がある。
このchunked responseの返され方は、必要な情報ばーっと流されて、
一通り終わったら初期ダウンロード終了のメッセージが届く。
それ以降もマスタに変更があったらメッセージが届く。という感じ。
んで、例えば営業日みたいなのは1日1回しか更新されないのは初期ダウンロード分だけで十分な情報になる。
当営業日分、翌営業日分の2レコードが届いて終わり。
ここまではいいんやけど、初期ダウンロード完了のメッセージが届くのが、
営業日情報を受け取ってから20秒後とかになる。
営業日情報が届くまで1秒以下で、そのあと何もしていない時間が20秒あって、やっとレスポンスが終了する。
2件データを受け取ったら終わりというつくりにすることは可能やけど、
初期ダウンロード完了レスポンスがあるんやから、それを正しく使いたい。
でも20秒待つのはつらい……。
また続きに書くけど、マスタデータダウンロードは直列に処理する必要があったりもする。
取引時間中に叩くようなリクエストではないとしても、やっぱり不便よなー。
マスタデータダウンロードも直列に実行する必要がある
上の項目でも少し触れたけど、マスタデータダウンロードも他の注文リクエストなどと同じく直列で実行する必要がある。
20秒無駄な時間を待たされるだけでなく、その間他のリクエストが通らないということ。
リクエスト実行中です。みたいなエラーが返されるのでもなく、待機させられる。
注文は逆転したら困ることもあって、ライブラリ側で直列に実行できるようにするけど、
マスタデータの取得は並列に実行できてほしい……。
おわりに
まだ読み取れてないだけで、上記以外にも微妙な仕様があるかも。
kabusapiから乗り換えるかどうかの判断は難しい。
ただ、どんな環境からでもリクエストできるならおいしいし、
マスタ系の情報を立花に依存し、それ以外の動きはkabusapiに依存するなんかも悪くないかも。
更新履歴