I’m James Stewart and I’m one of the Technical Architects working at GDS. Over the past few months I’ve been mainly focussed on the publishing tools and platform that underpin GOV.UK, and in particular on the APIs they use and provide.
Way 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 the modern web and are really important to GOV.UK.
They’ll help other people use the information on GOV.UK to build tools and services, which is one of the recommendations of Martha Lane Fox’s report. They also help us to build a site that can be iterated rapidly, with components that focus on their core specialism, and;
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.
That approach is as central to our approach today as it was back then. It’s become more and more crucial as we’ve grown as a team and begun to get further into the detail of what it means to build the robust, secure system that GOV.UK has to be.
Clarifying the roles
We’ve moved fast to get GOV.UK ready to take the place of DirectGov and Business Link. Initially we built our main APIs into our publishing tools so that we could quickly iterate the two in tandem. That was helpful when we started out but it wasn’t really allowing each component to focus on its core responsibilities. Dependencies between parts of the system became complex.
As time’s gone on we’ve split those responsibilities apart, partly to keep each part of the code tight and focussed, and partly so that we can more clearly understand what each piece is doing at any given time.
Administrative and editorial tools update data, public-facing applications read and present that data. Small, focussed applications provide the APIs to join them all together. They talk to each other using the same technologies that we all use every day when browsing the web.
Even though we’ve changed the exact details of how they work, the APIs we’re building now remain very similar to those you may have seen if you dug into the beta: driven by clear URLs and returning easily parsed JSON.
Listening to the chatter
One huge advantage of separating out components and having them talk via clear APIs is that it helps us make GOV.UK secure and robust. Key to building a secure system is being able to quickly tell if a given component is doing something unusual. Are there an unusually large number of requests for new passwords coming through? Is the interface that’s just meant to read information out of the database actually trying to update or delete that information? Information like that can give you an early warning that something’s under attack so you can respond accordingly (and, ideally, automatically).
By separating out our code and having the components talk via clear APIs it becomes much easier to set up automatic monitoring that will tell us when something unexpected happens. It also becomes easier to work out which parts of the system are working hardest and might need a few more servers to run on, or an extra cache to reduce their workload.
APIs that are built for the web and of the web really are central to everything we’re building here at GDS. That’s why we’ve worked hard to clarify their roles and to find ways of monitoring chatter.
In the next few weeks we’ll explain a bit more about how those same APIs we rely on internally can be used by other developers building other sites and applications.