Choosing an API

[Edo]

Lol, of course... those were in the lab at my uni. At BoNY we had something more like the NCD "pizza boxes". Man, I'm getting old

I wrote my first "basic" program on a DECwriter. That was back in the ... never mind. I guess I'm getting old too.

 

[spy]

I wrote my first "basic" program on a DECwriter. That was back in the ... never mind. I guess I'm getting old too.

It was actually the vt220's we had at uni IIRC... not old enough to have used a DECwriter. You're getting really old.

Was lucky enough to have one of these (either the 286e or 386s, if only I could remember that far back) in my dorm during the final years, connected via slip to some new fangled network (can't remember the name now, lol):

 

[Nerdytrader]

It was actually the vt220's we had at uni IIRC... not old enough to have used a DECwriter. You're getting really old.

Was lucky enough to have one of these (either the 286e or 386s, if only I could remember that far back) in my dorm during the final years, connected via slip to some new fangled network (can't remember the name now, lol):

look so nice.

 

[spy]

look so nice.

It was a good looking machine IMHO. But heavy, and used torx screws to get at the innards with those expensive proprietary drive bays (hated that)... pretty sure it was the 286e also. I can't imagine having had enough cash for the 386s. Still think I was pretty lucky though, it had a whole megabyte of RAM! ONE WHOLE MEGABYTE! Think of the possibilities.

 

[Businessman]

Hi folks: I have coding experience (C, C#, Python, etc.) but based on trying to do this a few years ago, I know I'll need to hire someone (resulting spaghetti code is a good sign) .. but my first step is to figure out which API to use. I have some algos I want to hard-code. Algos are complex, will trade several symbols, and must be resilient. I have used TT API (C#) in the past but found fundamental issues with it (example: could not place order #2 until #1 was acknowledged) ... I love the idea of the stateless TradeStation RESTfull API but scared of it (scared of getting information that is out of sync).

Any pointers / hints would be appreciated. My next step will be to find someone who can help code.

IB had a good API, not used it in years myself as have switched to Rithmic as i trade futures and IB raised margins so high on intra day futures it was a joke.

If it is stock trading you need to automate then have a look at the IB API.

 

[terr]

The best way, IMO, is to code to a meta-API that can, transparently, connect to multiple other APIs, which makes it easy to switch brokers or data streams.

Medved Trader, for example, is a PC application that connects to lots of brokers and data streams. It also has an internal simple Websocket API that will allow you to write your own code to trade through or monitor your accounts through any of the brokers it supports (and utilize most data sources it can connect to), as well as use its internal alerts/scanning functionality etc.

Here is the doc: https://www.medvedtrader.com/wsapi

 

[DeMurph]

'VMS', that was the first OS I worked on when I started my career (more than 30 years ago!!).

Oh dang! how old are you man? your experience is more than my age

 

[terr]

Oh dang! how old are you man? your experience is more than my age

Children. I started in 1978. 2nd and 3rd generation computers, machine language and Algol-68.

 

[spy]

The best way, IMO, is to code to a meta-API that can, transparently, connect to multiple other APIs, which makes it easy to switch brokers or data streams.

Same as my suggestion here:

That's what compatibility shim layers are for, right?

However, I think this often turns out to be "putting the cart before the horse". It's a good idea for systems programing. But, an application programmer IMHO, should simply choose the best API available and write against it. And, focus on keeping their internal application interfaces modular and clean.

Your broker is your partner and it should be unlikely that you'll want to switch away. If push comes to shove, then you add the shim/compatibility layer when necessary. This way you get something usable first. Otherwise you end up trying to build the perfect [meta]API and procrastinating, i.e. bike-shedding.

Building a shim or meta-API is slightly tedious but not rocket science by any means. And if you choose wisely to begin with the API will already be thought out by the vendor. You'll only have to swap a library file and maybe run sed or a macro on the header/source files to switch. Sometimes it's as easy as swapping a symbolic link, or adding a function into your shell. Here's one of my favorite completely over-simplified examples:

function stfu {
    nohup $@ &> /dev/null < /dev/null &
}

And, for the love of God, avoid #ifdef C macro style portability like the plague.

At least that's how I see things, again from an application development perspective. Make sure to choose wisely in the beginning though... if you're that worried look toward some standard (e.g. the FIX protocol).

P.S. No offense intended against your many years of Algol-68 experience

 

[terr]

Building a shim or meta-API is slightly tedious but not rocket science by any means. And if you choose wisely to begin with the API will already be thought out by the vendor.

The one I suggested already exists and is being used by a lot of people.

P.S. No offense intended against your many years of Algol-68 experience

Well, to be fair, maybe 2 years' worth. Then I moved to a better country and used/programmed the (at the time revolutionary) PLATO system. Which was like moving to a different century.