Imho, a good api is one that doesn't require any GUI components, and is relatively simple (no templates, etc). Redsky has this.. as well as mytrack (but their data isn't so hot). Nearly *everything* I've found is some bloated complicated crap like COM, MFC, etc
Good API's
- Thread starter Phlub
- Start date
Absolutely ! No COM, ActiveX, MFC, .NET and all the rest of the crap. It's overly complicated, prone to bugs, far too dependent on libraries that change at the whim of the OS/tools vendor, version dependant and all the rest of the grief you can get from this stuff.
For these purposes, a vendor should
1. Provide a decent formal specification of the protocol used by the API. It should be over a TCP/IP transport. It can then be used with OS/language of choice.
2. If the vendor wishes, supply API libraries for popular languages such as C++, Java etc. There is no reason whatsoever that these API libraries need have platform dependencies if standard languages such as C, C++, Java (and others) are used. .NET and all the rest of the stuff should be secondary to provide a simple, easily compiled, standard base API library.
How hard can it be to do do things properly ?
I would have to agree there. We much prefer to work with TCP/IP APIs as well, but not always possible. Seems that most brokers will have at least a local module that that manages connections, reconnect logic, server load balancing etc on the client side. Some are TCP based APIs but have local "Server" modules that have to be run, so you are still tied to the OS. (not a problem for us, but would be for non-windows users)
Well, it's not rocket science to make these 'local servers' portable too. I once worked on a fairly big and fairly complex telecomms server (~ 150K lines of C) and ported the thing from Unix to an NT service in a few days knowing nothing about NT services when I started. And I'm not the best programmer around by any means.
And they could open source them too while they are at it. Quote vendors are supplying a service not a software product as such.
End of rant.
Indeed Craig.
That's the way.
I would only add that no Java API library should be supplied without a C/C++ API library being supplied in the first place. From C/C++ you can wrap into almost any other language without the need for the top heavy bulky Java environment.
Yes, damn those top-heavy bulky environments! If it's not written in assembler it's just not right.
Nice try. There is one and only one language to write a library in if you want to provide choice to users: C. If you disagree, you're just wrong.
I agree with everyone else that the API providers are failing badly in most cases by tying their offerings to MFC, .NET, and all that locked-in crap.
Question is. Is anyone listening? I've talked to a few brokers about this many times and they said that basically no one else was complaining so they weren't going to do anything about it.
Well that's very open-minded of you. I do feel obliged to disagree though; IMHO Java's connectivity, portability and robustness make it a superb platform for most apps.
Yes, quite right. Vendor lock-in is an abhorrence.