API
Application programming interfaces (APIs) are important. They are an integral part of what makes the web work as, well, a web. Here at ONS digital we spend a lot of time thinking about and building APIs. We use them to ensure the collection of technical components we use to process and publish information can easily communicate with each other and we also want to ensure a sensible representation of our information is programmatically available to users external to ONS.
This is a post about some functionality we have recently made available to ensure our statistics are easier for people and computers to access. This is a very thin starting point and we have big ambitions to make as much of our information as open (in license, access and granularity) as possible. It is also about trying to be more consistent with the way we publish this information.
Consistently inconsistent
We have, like many big organisations, had a fairly organic development of our digital projects. Project funding, changes in technology and priority choices have meant that we have a range of websites that required users to think “which bit of ONS do I need to go to in order to get this information.” This is not a great place to have found ourselves and we are taking steps to turn this into “I will just go to the ONS website and get that thing I need.”
So, as Darren describes in his blog post, we are working on new functionality for the ONS site to best meet the needs of all our users.
We appreciate this is going to be something that needs to be handled with care. Our principles behind this are to try and make things better, not worse. This means no data are being removed from the web as part of this work. Wherever possible, URLs we have created will continue to be respected and we will standardise the way we publish new information.
Standard fun
So, this is where the new comes in.
Take a look and let us know what you think.
We have made some choices about how this is structured, which I would like to be transparent about.
- We are following the Swagger spec. We are doing this because we believe standards are important and this sometimes means following common sense as much as it does the W3C. Within that principle, the OAI and Swagger work seems like the best common model for describing RESTful APIs.
- We are separating the API from the website. This is not a choice we have made by chance; we are looking to define consistent identifiers for our information and our previous JSON API (which will still exist) was mapped directly to our human readable URLs and was starting to cause some issues.
- We have picked some languages to offer code samples. This is not meant to be the only ones we ever produce, so do let us know if we have missed anything that you would like to see covered.
- This is just the beginning. Our goal is to make all our information programmatically available. This means that the API switches from sometimes pointing as a spreadsheet to something you can use to ask detailed data questions. We are not as far as we need to be with this, but it is an important area of focus for us this year.
So – take a look. Let us know what we’ve missed and we will continue to invest in improving what we have created so far.
P.S. I often say “let us know what you think” on posts I write and very few people do. If you have thoughts on any of the things covered in this post, you can email me or contact me on Twitter, and the wider team are on Twitter as well (and will always respond). We also have connect and contact details at the bottom of every ONS web page. It is not an empty statement. We want to improve the service ONS offers and feedback is vital to that.