The Next Sports Exchange API is Coming

[AlgoTrader]

I think everyone has right to provide feedback to API design. API is supposed to be good for regular programmers, not gurus.

I think it is clear SOAP is going off, so praising SOAP/XML is counterproductive. The productive thing is to discuss the new API. The only problem is there is nothing to discuss for now

[Regi Keyz]

Extend API throttle for Forum user posts

Bloody Nora Algotrader!! You always got to argue a small point over detail.. and miss the bigger picture.

Sometimes I wounder if the person behind 'Algotrader' is actually my dad, coz that's his exact behaviour. Dad? Is that you ?!

Yes, Sure regular people can give feedback, I wasnt saying otherwise, just the more experienced people are likely in a better position to give better feedback.
eg Im sure wotsisname with years of experience can be more useful to Betfair team than myself with weeks of experience.. thats all.

Guys,

Whilst you are developing the new API, I'm guessing you will have a throttle built in to restrict the amount of calls a user can make..

Any chance you could put a throttle for some people posting on this forum?

Perhaps limit certain users to eg max 10 posts a year.. just for the benefit of humanity and mankind in general!

Anyone else with me on this?! Speak now of forever hold your peace hehe

!
:P

[AlgoTrader]

I write as frequent as I want. Do you understand?

Great Minds Discuss Ideas; Average Minds Discuss Events; Small Minds Discuss People. What is so interesting in my humble person? My person is out of interest for everybody here except you.

PS I don't care about your Dad.

[Fred77]

All requests and responses could be simple yet extensible delimited strings, no need for all that JSON bloat at all. Though for maximum performance and efficiency a betfair proprietary packed format would be best

AlgoTrader - I am aware that RPC/JSON has already been chosen - it's obviously a good all round solution and fine with me, you don't need to convince me

[Regi Keyz]

'I write as frequent as I want. Do you understand?'

Yes I know ya do, that's actually the problem..!

Sometimes your comments are helpful, though much of the time it feels like you are either posting purely to show off your 'authority'..or just to argue an almost irrelevent point, again to show-off your 'expertise'.

I just get a earache sometimes thats all.. perhaps I look like I overreacted with this one post, but you know I've seen another dozen posts from you before all to similar effect..

What's that bible quote: 'you got two ears and one mouth, so listen twice as much as you speak' etc.. Sometimes I think you got 7 mouths and 1 ear hehe

'Great Minds Discuss Ideas.. What is so interesting in my humble person? My person is out of interest for everybody here except you.'

Yeap, I agree it reads 'Great minds discuss ideas..' not 'Great minds argue little points just to have something to say!'

Right, I think we're officially degrading this thread, (you did start it tho!) I expect you want to have the final say, so go ahead and lets wrap it up.. and get back to discussing the new API which I think we all agree we are looking forward to

[MichaelRNye]

Will there be any sort of mailing list we can subscribe to for receiving updates about API releases & request for suggestions?

A new API sounds great! There are so many inconsistencies with the current one it will be good to have a bit more structure around the usage of it. I'm all in favour of making less calls with quicker responses. It will also be great to have complete market data available.

[Franklin1]

Virtual Bets

[LIST=1][*]Virtual Prices. The new API will return the same price data as the website.

A little but important point here: API users should be able to differentiate between 'virtual' bets/money and 'real' bets/money.

Seeing that this is possible on the website (by comparing the order book to the market information screen) it is in-line with the admirable aim "Anything you can do in a Betfair built interface can be built on the API", so I'll hope the new API allows this.

(I think providing no virtual bets at all is worse than providing virtual bets without the labels required to differentiate them, because at least without virtual bets the user can deduce them)

[AlgoTrader]

because at least without virtual bets the user can deduce them)

We should stop divide bets into real and virtual. That's the internal complexity that is out of interest. If I see best back at price 3.0 I absolutely don't care is it real or virtual.

I see no single reason why I should know whether a bet is real or virtual. I care about what the best price is and don't care what kind of virtuality it has

[Franklin1]

I see no single reason why I should know whether a bet is real or virtual. I care about what the best price is and don't care what kind of virtuality it has

You must only ever bet on single selections at one time then...

If I want to know what I can get size I can get filled right now on more than one selection I need to know what is virtual and what is real. If I ignore this then one of my selections will get filled, this will make the remaining prices on other selections less competitive, and my other order submitted, assuming all money was real, will not get filled.

Virtual prices are double counting of real liquidity. And I care about identifying real liquidity.

[AlgoTrader]

Virtual bets are real. Match engine is the same for site and API, so if you place a placeBets on en "empty" selectionId you may suddenly find it matched using "virtual" bet.

Yes, it creates illusion of great liquidity, that's it. I always try to work with selectionId with the lowest coef, there is lots of real liquidity there

[Peter Simple]

Virtual bets are real.

That`s true it is "real" money.

We should stop divide bets into real and virtual.

Only for a simple punter it is not of interest.

[Franklin1]

Peter: Thanks for the supporting post.

I'm worried now that if heavy API users cannot see the relevance of my point then we might end up with an API which is inferior (in this respect anyway) to the website (and the current API).

I'll try and use a simple example to explain (ignoring the size of bets):

Lets say we treat all bets equally and it shows:
Back Lay
A 3 3.05
Draw 2.98 3
B 3 3.05

Now, I want to back Team A and lay Draw and I want to know what price and size I can do this in at the current market price. From above it appears I can do both at 3.

BUT as it happens the underlying real money is
A 3 3.05
Draw 2.98 .
B 3 3.05

So once I back A at 3, taking all the money at that price (and in the millisecond before I lay Draw at 3) the market (real and virtual) will become:

A 2.98 3.05
Draw 2.98 3.05
B 3 3.05

and my lay Draw at 3 will not be filled.

So, my simple desire to know what size and price I can currently get filled at on more than one selection is not achievable unless we separate/label real and virtual bets differently.

Perhaps the best way to implement this would be a ExcludeVirtualBets argument in the API call so the user could specify.

[xaitek1]

I'm with Franklin1 on this, unless we've both missed the point of how virtual bets work.
If you are backing multiple selections in a single market you can't double count the amount available. You have to differentiate between what is real and what is not.

[xaitek1]

Also, with respect to data formats and protocols, JSON is a step in the right direction but is somewhat inefficient when compared to modern exchange protocols.
BF should be looking to provide a choice of protocols in the long term: JSON (or the like) for those who want to see and read the data in ascii format and who don't mind the performance hit that this incurs, and a packed binary protocol for those who want proper low latency and are prepared to pay for that level of service.
With respect to the appearance of the data, once I have written an exchange transport and it is fully tested, I have no interest in ever seeing the data in its raw exchange form. I am much more interested shaving milliseconds off my response times and increasing the probability that I can actually trade the depth that I see in the price messages.

I also think the API should always be a superset of the functionality available. As I see it, the website is mainly for people who care about who wins a race or match. Use of the BF API has gone way beyond that now and has many similarities to financial exchanges in its use.

[AlgoTrader]

With respect to the appearance of the data, once I have written an exchange transport and it is fully tested, I have no interest in ever seeing the data in its raw exchange form. I am much more interested shaving milliseconds off my response times

BF states everyone is equal (excluding Malta roundtrip for non-UK users). If we all have the same protocol it's not a problem. If anyone has super-efficient binary protocol that would provide a competive advantage then most of people will HAVE to switch to binary one.

I don't like the binary protocols but if there is one, I will have to switch to it. Single API for everybody is my choice, please no special APIs for those who can hire a dozen of programmers to do complex things.

Can you trade on financial exchanges? There is the Deutch Bank with million dollars infrastructure, FPGAs, heavily optimized operation systems and thousands of programmers worlwide. Fortunately, we have no such players here on BF