All of the editorial content on GOV.UK is available in full via an API. It’s the same API we use to communicate between the editorial tools and the apps that produce the pages you see.
As I said several months ago, APIs are the bedrock on which GOV.UK is built. Martha Lane Fox’s report made delivering high quality APIs a key objective of our work on GOV.UK. Building on APIs and with APIs in mind has been a key architectural principle in the design of our software.
Those who read the previous post will have seen some buttons we were then using to advertise the existence of our APIs. As we worked through the design in more detail and came back to our design rules we realised that for the vast majority of visitors to the site they were a distraction from the quick answer to their need that we’d promised. So the buttons have gone. The links haven’t entirely disappeared, and some would argue that their new home is where they should have been all along: in the HTML header alongside all the other ‘metadata’ associated with the pages.
Where we’ve built custom tools we’ve tried to make sure they provide useful content via APIs too. So for our ‘planner’ tools (maternity/paternity leave) the data can be exported as iCal or JSON. And if you take a close look at the URLs you’ll be able to work out how to get it for any date. Similarly all our ‘calendar’ data (eg. bank holidays) is available in iCal and JSON formats.
We think that’s a pretty good start, and we’re using those APIs ourselves to put the site together and to test it. What we’re not quite ready to promise is that this is the final form for these APIs. We’ve put together a quick “API explorer” (following the example of Flickr, the Guardian and others) at govuk-api.heroku.com.
It’s been really exciting to see a few people playing with the APIs already: Harry Metcalfe used it to explore word frequency on the site, Luke Vincent built his own search interface to the site, and Saul Cozens has built a WordPress plugin to embed GOV.UK content in your blog.
As with everything we’ve made, our APIs are subject to iteration and very much in beta. We’re conscious that right now they’re a reasonable way to get at the content, but we need to pay particular attention to how they work with tools like smart answers.
Given that the site is still in beta, the API’s will most likely change which could impact on developers who are building apps on top of them. As the beta evolves we will add versioning to get around this problem. We will also define support levels for our APIs as we move to a more solid footing. Based on the user feedback we get on APIs, we will look at creating curated packages in a future release.
And again as with everything we’ve made, we’re looking for as much feedback as we can get. If you’re so inclined, we’d love it if you explored the APIs a bit, let us know how you find them and what we can do to make them more useful for you. If you email us about something you’ve built we’ll also do our best to let you know as the APIs evolve so your code doesn’t break! We may even buy you a drink…
James Stewart is a Technical Architect at GDS. You can follow @jystewart on Twitter