APIs
I just noticed that the whereis.com.au API has been opened up to developers (right after I was presented with a 1997-esque “please use one of our approved browsers” roadblock-page when trying to visit the main site). Menno says that they had an API of some sort available a year ago when he asked them about it, but they wanted money, so this is a definite improvement.
I would actually be more interested in seeing an API for the Sydney Transport Infoline. There are plenty of interesting things that could be done with the trip planner: Dynamically-updating mobile apps (“OK, you missed that bus, instead catch this one”); next-bus-home desktop/dashboard widget showing the next few departure times for your commute home; GPS data (“get me home from here”), etc.
Jeremy Zawodny’s talk proposal From Open Source to Open APIs last week got me thinking about this stuff a bit more: To me, an API is usually something that provides some kind of functionality. But the value of what’s being wrapped up in many of the popular web APIs (Google Maps, Flickr, Facebook, etc) is really the data the APIs can work over. The fact that it used to be hard to make web sites that use maps, for example, has less to do with a lack of mapping software and more to do with a lack of legally unencumbered map data.
So why have web APIs at all in these cases, instead of big lumps of free-licensed data for anyone to integrate? The most obvious answer is that most of this data changes frequently: When this happens, the main value isn’t the body of archived information, but the provider’s promise to be up-to-date (services, not intellectual property, to frame it in familiar terms). But the data encumbrance problem doesn’t go away by itself: Unless the data (static and dynamic) is available under a free license, ‘open’ APIs are a huge vendor lock-in: End-users are still essentially relying on a data monopolist at the back-end, and application developers are still ‘sharecropping‘.