Public APIs are a vital feature of the modern web. Whether you’re looking at the ecosystem of Twitter and Facebook apps, tools for managing auctions on ebay, or code for embedding Youtube videos in a blog post, clear ways of integrating services are key for building more captivating web experience, and for bringing solutions to users where they are. It’s that latter point that underpins the recommendation in Martha Lane Fox’s report that: “the content, functionality and features of the service should … be widely available and open for re-use via syndication/apps.”
As we started to build the software underpinning the single domain beta we had to work out how to turn that from a direction of travel into a concrete feature. On one level, we could simply argue that if we structure our HTML well the pages themselves will function as our API. That’s certainly an aspiration but we can do more.
As with Alpha.gov.uk we’re building the beta as a series of small pieces, loosely joined. Those joins are enabled by APIs. And that’s the first round APIs we’ll open up to the public. So on our current development version of the site you might see a set of icons like this:
That JSON link gives you the same data we’ve used to build the page you’re on, and since this is a page where geography is significant, the KML link gives you the raw location data in the format we’re using to import it into Google Earth for sanity checking, while the CSV is used as part of our data gathering and cleanup process.
We found having these formats invaluable when it came to testing our “find my nearest” tool. The results weren’t coming out as we expected and it was only when we exported the KML file to Google Earth that we spotted all the register offices we were working with plotted just off the coast of Australia. A few minutes later we’d fixed the bug and it was all working smoothly.
We’re not just building APIs, we’re building on those same APIs ourselves. In software development that’s referred to as “eating your own dog food”, an unpleasant phrase for a now widely accepted best practice when building a site of any significant size. It’s something Paul Hammond and Simon Willison (then both of Yahoo!) discussed at the dConstruct conference in 2006, Amazon.com’s developers frequently talk about the large number of services they use to compose each and every page on their site, and the same pattern can be seen across the industry.
Separate pieces with clean APIs can be iterated rapidly, can be swapped out where requirements change, and ensure that each component can be focussed on its core responsibilities. It also means that the APIs the rest of the world uses will already have been put through their paces in a real production system, refined through implementation, stable and constantly monitored.
We’ll be talking more about how our APIs can be used to enhance other sites and applications as the beta launch approaches, looking at a variety of ways partners will be able to re-use our content and raw data to build on our work and processes.