61–70 of 70 posts
Any way of using the api's in 'test' mode? Maybe have the methods return dummy / delayed data ? Or maybe have one instrument of each type available for free so that people can create mockups and test wrappers ?
Wow this looks pretty awesome. As a student who is interested in relating programming to finance, this definitely looks like it takes care of some barriers that were previously in place. I'm extremely excited to look into this.
Then why not just learn with Interactive Brokers API, you get access to their TWS test system API which is great for learning purposes.
Anyone know a service that provides easy access to historical income statements, balance sheet, and cash flow?
S&P Capital IQ -- http://www.capitaliq.com Depends on your definition of easy I suppose, but they have a superior fundamentals database.
http://strataconf.com/strata2012/public/schedule/detail/2258...
Any way of using the api's in 'test' mode? Maybe have the methods return dummy / delayed data ? Or maybe have one instrument of each type available for free so that people can create mockups and test wrappers ?
I know internally we have a way to do this (use static files to test subscriptions / static requests). I'll ask if that is available in the package already or if it can be added.
My experience with using anything Reuters or Bloomberg is that you do not want their code anywhere near a critical system. It's poorly designed, poorly documented, low on features, hard to integrate, and incredibly expensive. Moving data from one place to another is a solved problem. But not if you are using RMDS. Then it's just a problem.
The second was a very rich set of all manner of indicative data--a superset of what you would imagine is behind the Terminal itself. This seemed to me to be a very cleanly specified and implemented system. And it was quite feature rich.
I am not clear on what relationship this has with their current offering.
My experience with using anything Reuters or Bloomberg is that you do not want their code anywhere near a critical system. It's poorly designed, poorly documented, low on features, hard to integrate, and incredibly expensive. Moving data from one place to another is a solved problem. But not if you are using RMDS. Then it's just a problem.
I can't speak for Reuters, but I have worked with two generations of Bloomberg data. One was a trading backfeed over TCP/IP that was pretty complicated to implement. For example, whenever my side crashed or exited, I had to call the NY contact to restart his server end. That was a pretty tricky, but once up it was quite steady. And it was attached to a very critical trading system. The second was a very rich set of a…
Note that ths is just an API - to use it you still need to be a subscriber, and nothing they offer is cheap. In the tradition of their Excel APIs, this doesn't even come close to giving automated access to their entire database. This API seems like a marketing tool designed to get people to build algorithmic applications around expensive real time feeds from Bloomberg.
Having worked there, I can see that this is a very powerful move towards solidifying marketshare for then. They were drowning in complexity. Opening the API will allow them to acquire any small innovating startup at a fraction of the cost it would have taken them to develop inhouse.
Earlier quoted context omitted.
Also check out Activetick (no relationship with them) for a few months. It works on all platforms. They even had an example program that made their API accessible via HTTP. I got away just with that. I compared their data with another feed and they matched. http://www.activetick.com/activetick/contents/ActiveTickFeed...
Looks like ActiveTickFeed works on a per-symbol-subscription model. Full market feeds are different because you don't subscribe to specific symbols.
I had no idea there was a service to stream the entire market to your desktop. my mind is blown.
Earlier quoted context omitted.
What am I supposed to do with a free programming interface if I have no access to the data? Maybe they want to "force" other market data providers to define a common standard for this kind of API? Or maybe they hope it will bring more third-party partners interfacing with their systems? I dont understand if they have also "test feed" that you can use to develop without an expensive agreement (afaik a bloomberg machin…
Ok this example probably clarifies the rationale: "A programming interface that is proprietary severely limits the options for firms that use them. Typically, a proprietary interface is contractually tied to the associated product. If the client decides to stop using the product, any references to the interface must be removed from the client’s applications. Further, the proprietary interface may not be copied and us…
http://www.opengamma.com/blog/2012/02/02/bloomberg-market-da...