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.
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.
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.
7 comments on “API”
Thanks for making information more freely available with the API.
I am learning about APIs and how to use them. This may be a daft question and obviously you are making the data available but not how it is embedded in other sites, but do you know if it is possible to display up to date time series data that is published monthly for example, so that my website would always have the latest data? I realise this depends on writing a script to automate the fetching of data, but is it possible to automate this process in theory?
I’m using R to retrieve data via the JSON API but the problem is that I can’t make multiple requests this way, which means it’s not efficient. For example if I want to get CPI and core CPI data, I can’t do this with just one line of code in R. Is there a way around this please?
Hi, thanks for your comment.
Not in the current API unfortunately. We have been working on a new API to replace this which is currently in public Beta. More details of this are available here – https://developer.beta.ons.gov.uk/
It would be great to get any feedback you have on this.
Product manager, ONS website and API.
I have been using the current API to download data using a python script without issue, however in October it stopped working and cannot establish what has changed. Can you shed any light on this?
The changes referred to by Rob Chambers have been made,which probably account for the issues you have encountered.
There’s an update on our API service in this recent blog from Rob Grant: https://digitalblog.ons.gov.uk/2021/02/15/how-to-access-data-from-the-ons-beta-api/
Hopefully this proves helpful. If you need anything further, please email firstname.lastname@example.org
Hello, how can I implement the API in Java?
Thanks for your work developing this.
I seem to be able to access the example CPIH01 dataset on the new Beta V1 API, but not many other datasets that I use often: e.g. PN2, MRET, PUSF, UKEA etc.
Is there something wrong with the request:
r = requests.get(‘https://api.beta.ons.gov.uk/v1/’ +