API Roadmap Survey

[RedDeadFred]

Intrigued by this, why does the position matter? Just loop the market changes in rc, select the [‘id’] and do what you want with it, same with img.

I should've clarified - if using a non-streaming parser which will load the entire message into an intermediate data structure, and you don't mind doing hash-table lookups while accessing fields, there is no issue.

If using a streaming parser, and if the id and img field were at the start, you could start processing the message before it has even been completely received from the network, avoid extra memory copy and avoid using hash-tables or loops to access fields.

[LiamP]

+1 for runner names in Stream API.

Another thing - the runner IDs are at the end of the JSON rc objects, so I need to temporarily store all of the data before the ID, then copy it into my model once I get the ID. If the runner ID was at the start of the JSON object I could stream the data directly into the right model.

Likewise for the img field, which is the last field, even though it determines how the preceding data should be handled.

Having these fields at the start of the JSON objects would make client code so much simpler.

Intrigued by this, why does the position matter? Just loop the market changes in rc, select the [‘id’] and do what you want with it, same with img.

[RedDeadFred]

+1 for runner names in Stream API.

Another thing - the runner IDs are at the end of the JSON rc objects, so I need to temporarily store all of the data before the ID, then copy it into my model once I get the ID. If the runner ID was at the start of the JSON object I could stream the data directly into the right model.

Likewise for the img field, which is the last field, even though it determines how the preceding data should be handled.

Having these fields at the start of the JSON objects would make client code so much simpler.

[tarb]

I have a couple little pain points,

Can we have market name and selection names returned in the stream? Having to make repeated calls out to listMarketCatalogue just to grab the names is annoying. This can leave UI's in an incomplete state when the stream pushes new markets and you must then request the names from lmc - its also not an insignificant problem to solve if you want to batch a request for multiple markets at the same time and have it be fault tolerant to network errors. Adding the names to the MarketDefinition and RunnerDefinition would be a very insignificant increase in payload size. But still if this was a major concern then a field in the MarketDataFilter could be used to control this behavior and allow latency sensitive applications to keep the current behavior. Its also seems worth noting that the pro historic data already does exactly this, with the MarketDefinition and RunnerDefinition both having a name field but otherwise being identical to the stream data.

With the stream having a market limit of 200 markets it can be hard to (or sometimes impossible) to subscribe to a whole country/eventTypeID, this mainly happens when a few days markets are loaded in advance (AU 4339 is bad for this). I would love to have a filter which controls how far out to return markets, ie only return markets whose start time is in the next 24 hours. A bump to the default 200 market limit would also be nice.

Cheers

[HarryHindsight]

Having two factor authentication optional for log in .

Horse Racing GPS feed ;
In Play betting is a point of difference that Betfair can offer their clients. Having applications that can level the playing field against on track players can only be good.

[BetfairDeveloperProgram]

Thanks MarkoB, are you specifically referring to a test bed style system?

[MarkoB]

Virtual wallets ASAP please.

[BetfairDeveloperProgram]

Which feature would you like to see provided via the Betfair API?