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.
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.