最近因为一时兴起，开始研究程式交易
去跑了几个交易商 申请了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啊

这是责任归属问题。