You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Interactive Brokers API wishlist
- Thread starter globalarbtrader
- Start date
Published today on my blog:
However now I have been running my system for around a year with real money (with several months of test trading before that) there are a few things that are really annoying.
...
Any other stuff you guys feel is missing?
IMO, they should not have created language-specific libraries at all, or at least not to the exclusion of an open wire protocol of some sort. If they had a wire protocol defined (e.g., JSON over REST, just spitballing here), you could code up a simple library in your favorite language and be done with it. Then, perhaps IB could provide a few "official" libraries for the most common languages. There is no reason that a trading API need be complex at all. The rest of the world figured this stuff out years ago.
Last edited:
Rest is one of the worst ideas for order submission and fill communication because it is the least stable and most sensitive to errors or network issues. Ignoring the fact that it is also the slowest of all technologies it may serve a purpose to stream data or especially to fulfill historical data requests. But forget latency sensitive strategies for that. There are extremes, HFT and Rest based streaming on the other hand but IB is latency sensitive enough to make APIs that strike a balance really useful. REST in any case us way too slow to serve even IBs snapshot data. You would end up with a bottleneck that results in quotes getting Queued up somewhere in the chain.
IMO, they should not have created language-specific libraries at all, or at least not to the exclusion of an open wire protocol of some sort. If they had a wire protocol defined (e.g., JSON over REST, just spitballing here), you could code up a simple library in your favorite language and be done with it. Then, perhaps IB could provide a few "official" libraries for the most common languages. There is no reason that a trading API need be complex at all. The rest of the world figured this stuff out years ago.
As I said in my post, earlier, I was just spitballing with REST. A trading API doesn't need to use REST. It could easily open up a persistent socket and just exchange JSON-encoded messages (or whatever -- just avoid XML as it's a heap of needless complexity). The point is, a simple wire-level protocol is far better than a bunch of proprietary libraries coded in just a handful of languages. I'm looking at using Clojure + Java API for my work with IB's API, driven primarily because Java libraries exist and Clojure, being a Lisp, rocks. But it would be nice to be able to use something like Racket, too. I suppose I could do that with some FFI interface and the C++ library, but now we're talking about a bigger project.
Just get the job done in whatever language you prefer instead of Masturbation over language choice or preferred implementation. This is finance where nobody cares about engineering beauty but when you get the bloody job done.
As I said in my post, earlier, I was just spitballing with REST. A trading API doesn't need to use REST. It could easily open up a persistent socket and just exchange JSON-encoded messages (or whatever -- just avoid XML as it's a heap of needless complexity). The point is, a simple wire-level protocol is far better than a bunch of proprietary libraries coded in just a handful of languages. I'm looking at using Clojure + Java API for my work with IB's API, driven primarily because Java libraries exist and Clojure, being a Lisp, rocks. But it would be nice to be able to use something like Racket, too. I suppose I could do that with some FFI interface and the C++ library, but now we're talking about a bigger project.
As I said in my post, earlier, I was just spitballing with REST. A trading API doesn't need to use REST. It could easily open up a persistent socket and just exchange JSON-encoded messages (or whatever -- just avoid XML as it's a heap of needless complexity). The point is, a simple wire-level protocol is far better than a bunch of proprietary libraries coded in just a handful of languages. I'm looking at using Clojure + Java API for my work with IB's API, driven primarily because Java libraries exist and Clojure, being a Lisp, rocks. But it would be nice to be able to use something like Racket, too. I suppose I could do that with some FFI interface and the C++ library, but now we're talking about a bigger project.
The source for the 'proprietary libraries' is distributed freely to API users, so you can read the code and write out the wire level protocol, if you so desire. This would be a pretty pointless exercise IMO but you could implement in the language of your choice.
There is likely a very good reason they don't give most people direct access (via FIX or whatever technology) to their servers, and I am guessing that by going through TWS it serves some risk / sanity checks. In fact IB has a FIX/CTCI option if you pay more. Why pay more? Probably because people who can afford it are more likely to know what they are doing and pose less risk to the firm.
If you really wanted, you could interface directly with the exchanges, and implement their wire protocols directly in whatever fashion you want. Go for it. Of course, this would require that you actually a) have money and b) know what you are doing.
The source for the 'proprietary libraries' is distributed freely to API users, so you can read the code and write out the wire level protocol, if you so desire. This would be a pretty pointless exercise IMO but you could implement in the language of your choice.
There is likely a very good reason they don't give most people direct access (via FIX or whatever technology) to their servers, and I am guessing that by going through TWS it serves some risk / sanity checks. In fact IB has a FIX/CTCI option if you pay more. Why pay more? Probably because people who can afford it are more likely to know what they are doing and pose less risk to the firm.
If you really wanted, you could interface directly with the exchanges, and implement their wire protocols directly in whatever fashion you want. Go for it. Of course, this would require that you actually a) have money and b) know what you are doing.
Yes, the source is there and one could reverse engineer the wire protocol from that, but then you're left trying to track protocol changes, etc. Ultimately, that can become a nightmare. Better to use their libraries, IMO. The last thing you want is to blow a trade because you didn't do a good job reverse engineering and missed a corner case.
Yes, you could always directly interface with the exchanges, but I'm just a small timer with a six-figure account wanting to automate my trading so I don't have to do it manually. I certainly know what I'm doing within my sphere, but I'm definitely in the high stakes, professional crowd.
Yes, the source is there and one could reverse engineer the wire protocol from that, but then you're left trying to track protocol changes, etc. Ultimately, that can become a nightmare. Better to use their libraries, IMO. The last thing you want is to blow a trade because you didn't do a good job reverse engineering and missed a corner case.
Yes, you could always directly interface with the exchanges, but I'm just a small timer with a six-figure account wanting to automate my trading so I don't have to do it manually. I certainly know what I'm doing within my sphere, but I'm definitely in the high stakes, professional crowd.
If having a robust trading system is important to you then you *will* go through the work of ensuring that whatever code you write is correct. The pros don't miss corner cases -- the ones that did are already out of business.
If having a wire protocol (or insert feature X) is important to you it should not be that difficult to write a tool to automate the process of reverse engineering the wire protocol (insert feature X). And yes, such a tool would need to have 100% correct output, but if you're in the business of automated trading you're already used to writing 100% correct code anyways.
Honestly I am not a fan of IB's design choices either. However, I doubt that sitting around and waiting for IB support/engineering to change their policy on their API is productive -- they have not done so in the years so far, I don't see why they would start now. In other words you can work with them or work around them, but IMO complaining is just not going to lead you to success in automated trading.