"* 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."

"* 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."

More...

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:

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

More...

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.

* 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.).

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.