Are there any Broker Web Service Trading API ?
- Thread starter rebtut
- Start date
It does not sound appealing.
In it's simplest form, package up + send html commands and then have to wait for replies? And break apart the acknowledgment?
Not sure why someone would want to do this... ...possibly if they know how to write html.
Go with IB api or equivalent, more control.
In it's simplest form, package up + send html commands and then have to wait for replies? And break apart the acknowledgment?
Not sure why someone would want to do this... ...possibly if they know how to write html.
Go with IB api or equivalent, more control.
Quote from rebtut:
The problem is it is proprietary. What if I have several brokers, I will have to learn differents api, use different platforms.
And no it's not about html, but XML / JSON / HTTP protocol, all standards
GAIN Capital has a web services API for order management. http://www.gaincapital.com/forex_api.html -- I haven't used it, but it's the only I've seen that interfaces this way.
"* The trading functions are initiated by the client in the form of a request. This logic is implemented using Web Services; an XML based SOAP interface that uses HTTP as its transport. Web Services have become the de-facto B2B protocol of choice through their ease of use and cross-platform portability."
Thank you very much, that's exactly what I was looking for. Yes for sure "Web Services have become the de-facto B2B protocol of choice" and I think brokers who will offer this will gain some competitive advantages on those who don't because it will allow more people to feel at ease with trading automation, that's what I think and if you are interested I wrote an article here on how to add value to Online Business:
"Business Startup Innovative Idea: beyond SAAS and E-Commerce"
http://reboltutorial.com/blog/rebol-for-business-startup/
Quote from rebtut:
The problem is it is proprietary. What if I have several brokers, I will have to learn differents api, use different platforms.
And no it's not about html, but XML / JSON / HTTP protocol, all standards
optionsxpress (www.optionsxpress.com) used to have a web-based API...but that was several years ago. Don't know about now.
I understand where you're coming from but it's a little bit different in this industry.
There are a bunch of brokers that support an API that doesn't require desktop software on the client. These aren't what you might call "web-based" APIs as they generally aren't based on the stateless HTTP protocol.
Google "FIX protocol" to get an understanding of the industry "standard" for a start.
Brokers will often also offer their own proprietary API in addition to FIX.
So I can run some broker software on my computer that has an API and links to my account... or I can run some other software on my computer that connects to my account..
How the hell would I know the difference?
I feel a little more secure with the broker software on my computer interfacing their pinhole firewall all with their proprietary communication protocols, thank you very much...
Interactivebrokers has standalone software with an API and browser based software with an API and most third party developers recommend using the standalone software... why is that?
How the hell would I know the difference?
I feel a little more secure with the broker software on my computer interfacing their pinhole firewall all with their proprietary communication protocols, thank you very much...
Interactivebrokers has standalone software with an API and browser based software with an API and most third party developers recommend using the standalone software... why is that?
Many differnces for professionals (a.k.a. programmers):
* Client software runs sometimes badly for servers without user interface
You need tobe logged in (to run it), or it may get stuck with a dialog that noone can click. I remember reading about friendly IB (or was it someone else?) sometimes bringing up a "you need to update your client" dialog (!) waiting for someone to press "ok" and NOT ACCEPTING ANY ORDERS THROUGH THE API UNTIL THAT HAPPENED, without error, just getting stuck. This is pretty much as bad behavior as it gets.
* It is per definition FAT and requiers updates often. THis is because it is a lot more than the API, which often is an afterthought. A C++ linked in API (like I use riht now with Rithmic) is more stable as it ONLY handles the communication aprt, and with HTML there is only little chance left for an update required due to a coding error in the third party code.
* It is often a pain to manage. I write my own servers to trade at the moment. I use different ocnnectivity (RIthmic at the moment, only, but the system is expensible). While this is a Library that i Have to link in, I can distribute it and update it automatically with my package installer (because, incidentally, my trading system will run distributed to about 4-6 computers in the beginning). Client software often is hard to integrate into proper system management.
And, if you take out market data feeds, which obviously suck as SOAP per definition.... a SOAP / Web service based API is really good enough for things like order handling or account handling, even if that means pulling X times per second to get a notification whether something got filled. Not super efficient, but good enough. The main problem a SOAP approach has :
* Soap is not efficient. This sucks to transfer a lot of SMALL particles - emphasis on both, small and size, like market updates.
* Soap is uni-directional in the standard - there are some ways to achieve bi directional, but they are propietary (WCF from Microsoft allows publishing events, which then get polled from the client behind the bars, and I think I Read about a TCP chanel they use - no html - that allows real time event forwarding), which leaves on in a problem getting things like status updates (order filled etc.).
* Client software runs sometimes badly for servers without user interface
You need tobe logged in (to run it), or it may get stuck with a dialog that noone can click. I remember reading about friendly IB (or was it someone else?) sometimes bringing up a "you need to update your client" dialog (!) waiting for someone to press "ok" and NOT ACCEPTING ANY ORDERS THROUGH THE API UNTIL THAT HAPPENED, without error, just getting stuck. This is pretty much as bad behavior as it gets.* It is per definition FAT and requiers updates often. THis is because it is a lot more than the API, which often is an afterthought. A C++ linked in API (like I use riht now with Rithmic) is more stable as it ONLY handles the communication aprt, and with HTML there is only little chance left for an update required due to a coding error in the third party code.
* It is often a pain to manage. I write my own servers to trade at the moment. I use different ocnnectivity (RIthmic at the moment, only, but the system is expensible). While this is a Library that i Have to link in, I can distribute it and update it automatically with my package installer (because, incidentally, my trading system will run distributed to about 4-6 computers in the beginning). Client software often is hard to integrate into proper system management.
And, if you take out market data feeds, which obviously suck as SOAP per definition.... a SOAP / Web service based API is really good enough for things like order handling or account handling, even if that means pulling X times per second to get a notification whether something got filled. Not super efficient, but good enough. The main problem a SOAP approach has :
* Soap is not efficient. This sucks to transfer a lot of SMALL particles - emphasis on both, small and size, like market updates.
* Soap is uni-directional in the standard - there are some ways to achieve bi directional, but they are propietary (WCF from Microsoft allows publishing events, which then get polled from the client behind the bars, and I think I Read about a TCP chanel they use - no html - that allows real time event forwarding), which leaves on in a problem getting things like status updates (order filled etc.).
I think your points are all valid though I don't think the OP had SOAP necessarily in mind. Probably more along the lines of REST APIs, JSon etc.
For order placement/management, where confirmations etc. can be asynchronous, I'd hate to have to implement some kind of polling over HTTP.
Instead, a web hook a.k.a. call-back URL would be better:
http://webhooks.pbworks.com/
However, that would necessitate running a web-based server/service capabable of receiving those call-backs (potential security issues)
Frankly, I can't see the benefit of using these web-service (be it SOAP, REST or other) technologies for the problem domain of account management, order placement etc. OTHER than the ability to leverage all of the tools and libraries that have sprung-up around these fashionable areas over the last few years thanks to the likes of Flickr, Facebook, Twitter et al.
I guess that is what the OP is suggesting and actually I'm surprised none of the trendy brokers have jumped on the "mashup" bandwagon and offered a REST API for something or the other even if it's not for order placement.