The Big Elephant in the Room?

[Lopiner]

First of all let me recognize the amount of work that i'm sure the BDP team is putting in this new API. I'm sure that something like this is not an easy task to accomplish and that sometimes we don't see the full picture and start to criticize too early.

That being said let me share with you my thoughts.
As i learned here in the forum the old API relied on outdated technology, had an huge overhead on each request/response and had limitations on its design so an update to a more lightweight technology like JSON was very welcomed.

Some people didn't like that but some people just don't like change so many of us didn't listening to them. I myself thought that it was a lot of work to update but eventually it would be a good thing.

Then came hell.

As a developer with very few experience i started to learn about JSON and slowly started to figure out the amount of work that i would have to do to upgrade to the new API.
There is no descriptive language file for the new API like the WSDL in the previous one. This means that you will have to build all of the Request/Response/Error classes for each of the requests. As an example a single request (placeOrders) has almost the amount of lines of code than all of my requests in the previous API.

Then we have to Serialize/Deserialize all things from JSON to the Objects and the other way around. Here we have to make a lot of Error Handling on our apps.

Finally there is the request to the server, this part is relatively simple but we have to account for errors, timeouts and build exit strategies so the Errors objects of the API will be filled and our applications warned about.

Then there are options that i assume the BDP team made that i don't think are the right ones. One is the API is case sensitive and that brings a lot of sensibility (i rather have a more robust thing with all things being case insensitive). Then there is a over normalization (i don't know if this is the appropriate term) of some objects like the PlaceOrders. There's really no need to create all those nested objects, something like this is much simpler:

MarketID
Orders()
    SelectionID
    Size
    Price
    PersistenceType
    OrderType
    Side

Then there is the specific case of VB.Net that i believe, by the success of the VB.Net topics in here, is the most popular language to develop for the BetFair API. VB.Net has the " as the string delimiter and JSON uses the " symbol for separating fields. This would be no problem if VB.Net had a global escape symbol but it doesn't so a simple JSON request string looks like this:

"{""filter"":{""eventTypeIds"":[""" & EventTypeId & """],""marketCountries"":[""GB""],""marketTypeCodes"":[""WIN""]},""marketStartTime"":{""from"":""" & dateNow & """},""sort"":""FIRST_TO_START"",""maxResults"":""1"",""marketProjection"":[""RUNNER_DESCRIPTION""]}"

This is a problem that has no culprits, it just a bump.

In summary it's a lot harder to develop for this API and i believe a lot of people that have developed to the old one will not be able to upgrade their Apps/Bots.

Some of this issues could be resolved by the BDP Team if they developed a descriptive file like JSON Schema (or even libraries for the different languages).

I believe that at this stage a lot of us don't have the time or the resources to build apps/bots in this new API.
I'm a beginner developer and don't really know if this issues can be address and if they are really obstacles. I hope some of the more experience developers can leave us with some advice.

Thanks

[AlgoTrader]

I see you have problems with a new API. My opinion is very different, the new API is great!

First, you should aware what JSON is. JSON is not a string, it's Java Script Object Notation. Any JSON is valid JavaScript program. Yep, JSON is executable code. If you stop to think of JSON as string format and start to work with it as dictionary object, then stuff imediatly go simple.

Second, there is no need for schema. Every JSON is easily converted to dictionary. {"a":"stuff", "b":2} is just a dictionary with two keys. C# has a dictionary type, Dictionary(TKey, TValue). Key is always string, value is (trick!) dynamic. Value may be dictionary itself, no problem, or array/list.

There are much easier languages that work with JSON natively, surprisingly it's JavaScript, the other are Python, Ruby, etc.

[Lopiner]

Thanks for the info AlgoTrader

That must be it, my problem is lack of understanding of what JSON is and how to work with it. I will continue to investigate how to work in Vb.Net and C# with the new API (i understand that this languages aren't the most appropriate but i have no idea on how to build desktop applications with javascript, python or ruby and i have a lot of code written that i want to reuse).

I'm really lost on how to use the new API without constructing classes for the Requests/Responses/Errors. Maybe the BDP will help us out with more complete sample code (and in VB.Net).

I will wait until i can get an understanding of what really takes to work with JSON before i develop any more code for this new API.

I would love to ear more user experiences with the new API

[Peter Simple]

There are much easier languages that work with JSON natively, surprisingly it's JavaScript, the other are Python, Ruby, etc.

This is a topic for advanced programmers. Many beginners start with Visual Studio and here are Visual Basic or Visual C# the first choice for them. And for the most hobby programmers the knowledge of such a language is sufficient for all their projects. That`s why i think Betfair should support this group better.

[AlgoTrader]

C# is certainly not a beginner's language. It is much more complex than Python or JavaScript. C# requires lots of concepts to know. I use it at work extensively, but never in hobby projects

[Peter Simple]

When you start with programming you do not need delegates and many advanced features and for small projects a simple procedural programming style is often efficient. It is a easier in Visual Basic but both languages are now very similiar.

But the big advantage of Visual C# is that you can work with Visual Studio (Express) and there many resources(books, example code and son on) for learning the language.

When you leave the beginner Level you choose the language which is the most productive because every language (script) has it owns strength and weakness.

[Hannible Lector]

VB JSON Parser Library

http://www.ediy.co.nz/vbjson-json-pa...xidc55680.html

I have developed an app using the old API and like others have been holding off changing to the new API because of the difficulty with JSON and Visual Basic.

Maybe the free parser library http://www.ediy.co.nz/vbjson-json-pa...xidc55680.html will help with the new API-NG.

Introduction to JSON for Visual Basic 6
VB-JSON is a Visual Basic 6 class library for parsing and emitting JSON (Javascript Object Notation) and can handle nested arrays and objects in the data. It does not rely on the JScript engine for parsing.

JSON is a useful and compact format for data interchange between a browser based JavaScript client program and a VB6 based data server, and also for storing structured meta data in a text field. It can also be used as an efficient RPC transport protocol and compresses well using GZip. The project also includes a fast string builder class for assembling the JSON data string at a high speed.

----
Note: I have nothing to do with this library I have just been looking for an easy way to convert to the new api.

[sun]

AlgoTrader, are you saying that API next is, in a sense, wasted on VB/VBA?

Is node.js definitely the best choice for a high-performance bot?

What is the best choice of language for a simple bot that you can in future easily distribute to clients without them having to install anything else? Javascript? Is it as easy as distributing an excel spreadsheet?

One other minor point: since API next is a fresh start, shouldn't the Python examples be for Python 3.0?

[AlgoTrader]

I know nothing about VB/VBA. I don't want to have another Holy War, so I have no desire to advertise node.js, etc. Node.js is good for me, but it can be nightmare for you, it depends on background and personal preferences. Asynchronous programming is more complex than synchronous, C# in version 5.0 finally has appropriate asynchronous stuff also. But async stuff is good for high-end bots.

Synchronous stuff is simpler, but has lots of limitations.

[betdynamics]

For anyone using .Net (whether it be C# or VB.NET) then you should download and use the JSON.Net library. It will make your life a whole lot easier!

[Lopiner]

Yes Hannible Lector, as betdynamics pointed out the JSON.Net is a great library to Serialize/Deserialize JSON.

Working with JSON in .net is a pain in the ass but by far not the biggest problem. The Biggest problem is creating the containers for the Requests/Responses/Errors. AlgoTrader said in a previous post that this was not needed but i'm still trying to figure it out how to solve my problems using dictionary's.