A recent blog post by Peter Krantz has sparked some interesting dialog on whether governments publishing open data for citizens and application developers need to deploy an Application Programming Interface (API) to their data.
The full post can be viewed here. It provides a nice set of considerations for governments looking at standing up an API to serve data to those that want to build civic apps.
Standing up an API to serve open data is a non-trivial undertaking, and governments would be wise to consider the risks and costs associated with doing it.
I’d also suggest that those in government evaluating the best ways to serve open data to end consumers review the details provided in the Open Data Handbook.
The Handbook (published by the Open Knowledge Foundation) provides a nice summary of the various ways that governments can serve open data, and provides a thorough listing of pros and cons for each:
The data should be available as a complete set. If you have a register which is collected under statute, the entire register should be available for download. A web API or similar service may also be very useful, but they are not a substitutes for bulk access.
Roughly three years ago, Tim O’Reilly defined a vision for “Government as a platform.”
Today, there are around 240 API’s listed on Programmable Web that identify as “government” APIs. This number is sure to climb in the weeks and months ahead, as more and more governments, public authorities and agencies deploy APIs for developers to use.
One such API, recently released as part of the relaunch of Regulations.gov, got my attention when it was highlighted by Alex Howard of O’Reilly Media.
The Regulations.gov API is part of a broader effort to use new technology and social media to engage citizens in the public rule making process.
The rise of API-based programming, and the dramatic success of REST in recent years over other kinds of API formats (i.e., SOAP), has helped spur lots of innovation and even changed the way that people build software. It’s encouraging to see efforts like the Regulations.gov relaunch try and tap into this energy and grab some developer mindshare to spur innovation.
But if governments are going to attract developers with APIs, then it makes sense to look at government APIs and evaluate them against other, more commonly used APIs to see how they stack up. People respond to incentives, and developers are no different – if an API is well documented and easy to use, developers are more likely to give it a try. The more “friction” an API has, the less likely it is to attract developers.
How does the new Regulations.gov API measure up? I decided to take a few hours to give it a test and find out. Here’s what I found.