最近因為一時興起，開始研究程式交易
去跑了幾個交易商 申請了API
不過券商的API都不是一般的Restful API
而是要你安裝他們編譯好的軟體，要你對自己的電腦下單，他的軟體就會代替你下單
也就是SDK的意思
問了他們工程師，為什麼不做成Restful 他們說因為會有安全問題
而且無論是哪個券商都這麼說
可能是小弟才學粗淺 所以想問一下
但如果是走一般的TCP/IP
用一個編譯好的程式把API包起來跟直接走Http request 安全性上有差嗎？
還有為什麼券商都這樣做
如果安全性真的有差別 那Line Pay之類的支付服務不也應該用同樣的做法?

每家有不同考量,傳統作法如果一直沒被改過,之後也不太會有所變動

可能要等TonyQ那樣的人到券商去才有機會...

有句俗語，沒壞的東西為什麼你要去動

框架發展史、客戶層級、管理層想法都會影響公司產品。裡面應該也是http通訊協定RMI,SOAP,RESTful，每個新協定出來就要客戶換一次，還是公司要維護多套？

多數大公司的決策者，都是不懂技術的

能不變就不變，能不開放就不開放

因為裡面人技術不夠力

出錯你要debug嗎？ 大概是這樣

不想動 怕出事

再來就是架構疊的太深 要整套做好可能要三四年以上

要錢的東西出事誰負責

財務相關的系統沒出大包或是重大疑慮就不會亂換系統的不然新系統出問題，長官的職位,你的工作就不保了

直接http 被ddos攻擊很難找到人和防禦

打rest api的門檻太低，太容易被ddos,但主要原因還是因延用舊的架構和舊的code

因為沒必要 而且沒效率

工程師還真閒，還回答你的問題，應該通通開除才是，哈人家的考慮是千百種因素，你的想法卻只有一個原因.....

可以順便 叫他們導入 docker、用 micro service 和 k8s

用API的人太少，做起來不合成本也是原因之一

回答您的問題: 1. 程式交易有專版可以問. 2.Trading專有名詞看起來瞭解有限. 3.有開戶入金嗎?下單前功課不少

講的line pay不用請款一樣= =...line pay會去跟銀行要驗證資料，銀行是最後一關line pay是不存交易細節的，用他那一套銀行還不被告死.."一些"交易細節，銀行都會存好存滿去年linepay新聞，支付標準安全層級和可追溯性都比較小

有喔 但每家不同 去看看fix協議

下單要收委託成交回報,Restful API無法主動接受訊息，所以背後都是Socket傳輸，另外因台灣法規關係要有憑證確認下單者身份,這也是無法使用Restful API的問題

應該說多數SDK是以自身發展為考量，而不是強調統一性

只要牽扯到金錢交易的問題，安全性的問題擺第一～ㄐ

收回報可以用websocket也可以用SSE，憑證簽章可以另外做只要規格肯給都做的出來，最主要的原因就是不想給太詳細的規格，就是要有一支程式在Client端，增加券商能控制的部分台灣一堆公司的觀念就是security by obscurity來取代管理

換新技術壞了出問題客戶流失你要負責嗎

待過一年證券的IT 我可以告訴你 這邊IT都是公務員心態居多真要用新技術他們寧願發包也不會改自己的code 他們的開發能量都用在因應法規調整與資訊安全他們的著眼點不在於技術潮不潮 而是做了能不能增加交易量與客戶基數

樓上專業

背後要跑一隻程式...你該不會是用python吧，某大券商的python API就是用讀寫文字檔到方式溝通，真是蠢到不行

樓上說的是forever嗎？

你是不是在真靠北工程師也有發文？

怕被當成報價伺服器 第三方資料撈免錢

安全問題 指的是 他的職涯安全 不是資訊安全

有法規問題啊

好像是憑證問題 js做憑證這幾年才開始發展

你想想 COBOL 為何活到今天，這疑問有點像初出茅廬問的

改系統成本高風險大又不一定會增加營收 何必呢 新技術跟架構的出世是要解決以前無法處理的痛點 若這個痛點影響公司業務不大 那真的不如不要改

有一些加密的細節不想被人知道滿正常的吧，說不定也有做Client Side Load Balancing等等，資安有很多方面，這樣做還是有好的地方吧

這跟台灣公司什麼關係？ gcp也是有提供sdk啊

這是責任歸屬問題。