My experiences using the new api and vendor operations

[StefanBelo.]

I implemented all api operations and grouped them to Account, Browsing, Betting and Vendor operations.

It is maybe a good idea if you offer these operations in similar manner offering 4 endpoints, mainly if you plan to add more methods.

None of vendor operations works at them moment. Should I have some privileges set to my betfair api account?

getAccountDetails and getAccountFunds does not work for jsonrpc. This issue was already reported by some users, your reply was to use json methods instead.

I implemented both protocols for my library, but I think most users will prefer json only, so for now is counter productive to put your developers resources to both protocols. Implement all features in json api only.

Well I can understand why you would implement interactive login, mainly when some countries require some additional processing for login to betfair, like Denmark for instance.

On the other hand, logout and keepAlive methods, please put such methods to an api calls.

I understand that sample code you provide is written by some students on internship at betfair, but even so you should check that code because most people here, will bluntly copy it without thinking what they do.

I think it is a good idea to use in your code Accept-Encoding: gzip, deflate for any client code when calling your api methods, just imaging the performance impact on your api servers when people will use interns code without it. I compared for instance the body size for calling upcoming events for all MATCH_ODDS, WIN, WINNER markets in 24 hours, what returns maximum for getMarketCatalogues, so 1000 records. 8065 bytes for gzip message body comparing to 71677 bytes in plain response.

I really like the new navigation for events and markets, but think how most people will use it. We need at least base market description included to getMarketCatalogues, and it is total traded on the market. From my perspective as a bot operator, I would like to filter markets by total traded amount and book value.

MarketProjectionType.MARKET_DESCRIPTION is not good candidate for adding such additional info, for browsing purposes only. You can solve this way MarketTime issues for horse racing markets, as Event.OpenDate what for other markets is suitable value, is not correct value for horse racing markets when browsing events/markets.

I programmed some basic GUI for testing your new api, and what maybe others here do not see are returned data. I noticed that for Swedish Football competition Allsvenskan U21, zou have got wrong data in databse, in the name you have got Allsvenskan U21\nAllsvenskan U21. Have a look at here:

http://www.betfair.com/exchange/foot...ion?id=2788619

Well, that is not api problem, but I am curious when, after couple weeks I saw it for the first time, a person responsible for entering data into your database will fix it at last.

Do we really need RegulatorAuthCode and RegulatorCode in CurrentOrderSummary?

That is the static information you can put to MarketDescription, or better to EventDescription, if you introduce such data.

[AlgoTrader]

Do not tell for everybody.

I certainly prefer JSON-RPC.
- single endpoint
- single method (POST)
- single success/fail criterion - presense/absense of result

In fact, JSON-RPC is easier to implement, at least to me.

[BetfairDeveloperProgram]

Hi StefanBelo,

Thanks for your feedback.

None of vendor operations works at them moment. Should I have some privileges set to my betfair api account?

We will need to permission your App Key to access vendor services. Therefore, please contact us directly at bdp@betfair.com

I have raised your other comments with our development team.

Thanks

Neil

[StefanBelo.]

Do not tell for everybody.

I certainly prefer JSON-RPC.
- single endpoint
- single method (POST)
- single success/fail criterion - presense/absense of result

In fact, JSON-RPC is easier to implement, at least to me.

JSON-RPC uses 2 endpoints. The account and vendor operations are offered from different end point.

[StefanBelo.]

Thanks Neil, I have just ended my tests and vendor operations works fine for json-rpc on the app key you generated for me. There is one problem with getDeveloperAppKeys method.

On json just listAccountSubscriptionTokens works returning active subscription tokens, so either you did not support the rest of operations, or there are some problems for simple json protocol.

As I already have 2 app keys assigned to my betfair account createDeveloperAppKeys fails, but why there is a problem with getDeveloperAppKeys?

The old app key is still valid and the new one works for all operations including for vendor ones, so calling getDeveloperAppKeys should return those two app keys.

Neil, I have got one request for your developers. I already mentioned it couple month ago when the first beta version of the new api was released for testing.

Have a look at enums MarketProjection, MarketBettingTypes, OrderStatus and the way your developers implemented api operations which use set/collection of such enums in market filter on so on.

There are some implementatios of emun flags in all programming languages, so instead of sending set/collection of enums, we could send just one value if all mentions enum types were declared as enum flags.

http://stackoverflow.com/questions/3...ribute-in-java

So instead of Set use EnumSet or BitSet in your java backend. This will simplified client code for languages directly supporting flag enums, as we could use:

MarketProjectionType.EVENT_TYPE | MarketProjectionType.EVENT

Enumeration Types:

http://msdn.microsoft.com/en-us/libr.../cc138362.aspx