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.
James Stewart is Tech Lead at GDS. You can follow @jystewart on Twitter, and read his personal blog.
6 comments
Comment by Building with APIs | Government Digital Service posted on
[...] back in the early days of this crazy ride I wrote about “Building APIs, building on APIs“. As I said back then, APIs, or application programming interfaces, are a vital feature of [...]
Comment by Open data: Magic from the inside out? (Part 3) - bm.wel.by posted on
[...] everything else. To take two of those – James Stewart explains the principle of ‘building APIs, building on APIs‘ whilst John Sheridan gives an insight into the structure behind legislation.gov.uk in his [...]
Comment by Outside-In APIs « a work on process posted on
[...] and the idea of an “outside-in model” resembles what I was getting at in “Building APIs, building on APIs“. I quite like the use of the phrase “outside-in”, and the iterative approach [...]
Comment by test for summary – read more option | pdunnetest posted on
[...] the data and information being freely available for other to commercially benefit from. I like the approach being built on beta gov, which allows a user to download the data used to make and create that [...]
Comment by Where Is He Now? « a work on process posted on
[...] who want a little more detail I’ve written a couple of pieces for the GDS blog: one about our approach to APIs and another about our platform [...]
Comment by The “local government” website « Carl's Notepad posted on
[...] the data and information being freely available for other to commercially benefit from. I like the approach being built on beta gov, which allows a user to download the data used to make and create that [...]