[TBA]: API Client Development

[Nibbles]

That was supposed to be a silly fanboy rant, though I do come across as too serious too often. I do have a tiny issue with this project though, and isn't with anything in particular, but it does seem like it was created just because, with no real purpose. That said I realize some really cool things have been implemented with the API/data server, like the BeachBots put in a flash player with videos of their matches. Still, it all seems hackish to me.

I have been using the data not to dynamically call another server every time I load a web page, but to import data to my own database of teams and scores (with penalties and a much more relational format).

Here is a web version of that simple test console for whoever to use: http://frcdb.redjacket.ws/tests/tba/console.php

If it wasn't obvious, I am a fan and long time user of PHP and XML (I also realize PHP was not designed to be an event-based language). I am expirenced with SQL, JavaScript, and have not learned but really, really like anyways, Ruby. I don't know what people like about Python, I have to use that thing inside SAGE Math to work out team strength algorithms, and it is the most reverse intuitive language I have ever seen (next to this one). I know C and C++ to work on the f/oss game BZFlag, and regularly use many different compilers and debuggers, including MSVC, which I will say has a great debugger (compared to, say, the text-based gdb). Never used .net, and have no need to.

Back to this API: It also seems like people are making this way overly complicated. Each of the get_* functions do the same thing, with the only variation being the method called in the URL. This is not how you program!! Good practice says you should make them the same function, and use an argument to provide different attributes. Sounds quite a bit like the tba_send_request which we are discouraged from using...
Now, In C++, different functions might be needed, as each function would return an array or std::list of structs or classes, but even then that isn't always necessary, as you could just return a std::list of voids or extended objects.

And like I mentioned earlier, there is a serious lack of error checking in the library.

<edit>RFC 2616 is the specification for HTTP and HTTP headers, including caching. Calling get_matches with no argument results in a memory allocation error that returns invalid XML. Also, I like the fact SOAP or XML-RPC wasn't used, but I would like to know the decision on why that was not the choice.</edit>

<edit><criticism type="text/x-constructive+criticism">
The API is horrible with relational data sets. I can't go in and say "find me the links to videos for all matches played by teams in Arizona" without importing the data to a relational database and throwing together a query: SELECT c.video_url FROM team a, team_match b, match c WHERE a.state="AZ" AND a.teamnum=b.teamnum AND b.teamnum=c.teamnum GROUP BY c.matchid
</criticism></edit>

[Greg McCoy]

Originally Posted by Nibbles

I do have a tiny issue with this project though, and isn't with anything in particular, but it does seem like it was created just because, with no real purpose.

The purpose is to provide a single place to organize match data and videos of matches. Before TBA, there wasn't a single good place to do this...FIRST seems to purge this information (at least from the Internet) yearly. For people that run team and regional event websites, this is a big timesaver because they don't have to reinvent the wheel pulling and parsing HTML pages intended for human viewing from the FIRST website.

Originally Posted by Nibbles

I have been using the data not to dynamically call another server every time I load a web page, but to import data to my own database of teams and scores (with penalties and a much more relational format).

I think this is the preferred thing to do...I update the Boilermaker Regional website every day with TBA info using a cron job (every 5 minutes during our event), rather than hammering TBA every time someone requests a page.

Originally Posted by Nibbles

Not to start a flame war, but no one cares about .net or Microsoft's open-source-wannabe-license.

I am not a fanboy of .NET or Windows by any stretch of the imagination, but disparaging the work of others (provided to you free of charge and in good faith) simply because you don't like the platform is downright rude. Arguing the merits of one platform/programming environment/toolchain over another really has no place in this thread, and should be left to a flamewar on some less useful forum.

I would, however, encourage you to help improve the TBA API. If you really want to reduce the get* functions to one function, go ahead and do it. If you want to add more error checking, go ahead and do it. If your solution proves to be superior, we might start using it.

[Nibbles]

I will say that having those multiple functions are a good idea, since it provides functional separation of methods (though not logical).

I posted a slightly better call to tba_send_request which I have tested and works great with errors or without, in all the situations I threw at it (It will throw notices). By the way, is there a better way to link to posts?

make_array is not usually necessary (it has its purposes), because of the method-style member access provided by SimpleXML (e.g. $xml->teams[5]->teamnumber). The only reason I would want to use it is where passing an array would be necessary, like array_map or similar.

I am still interested in the choice to go with a custom format did you ever consider SOAP or XML-RPC (I don't care for them, just want to know if that was a choice)?

Also, I know it looks cool, but PDFs are really inconvenient (I am talking about the API reference), I would focus more attention to developing mediarint stylesheets, and then making PDFs second.

[Shadow503]

I'll work on an ActiveX control for use in VB6 apps.

[Nibbles]

Originally Posted by Nibbles

I noticed other threads with people having problems. PHP5 has this great new thing called Exceptions. If there is an error, it will kill the execution of the script, unless the programmer has a method of catching and handling the exception.
The official PHP client is serverely lacking in error checking, for instance, if the API server returns a blank XML (XHTML, say) document, then no error will pop up.
...

I implemented the function into the class file, and implemented more error checking and exception throwing.

No license of any sort was included with the PHP5 library, nothing. I modified it with rights implied, and my changes are in the public domain (since there is no real logic or creativity in my changes). Feel free to re-license with whatever you want.

List of changes:

• implemented exceptions, replaced die() ("exit") calls too (see php.net/exceptions)
• TBA_Exception class for handling API errors
• PHPDocumentor comments
• prepended tba_ to all functions as a namespace

I believe I mentioned this, but documenting stuff as a PDF file is very annoying, HTML is fine thank you.