Government open data initiatives are flourishing, but are they at risk of falling short of their potential without an API-first approach?
Government open data initiatives are flourishing, but are they at risk of falling short of their potential without an API-first approach? According to Jason Hare, Program Manager of the Open Data Project for the City of Raleigh, the answer might be yes.
Hare came to that conclusion after conducting a survey of the public on the Open Raleigh website and looking at its usage.
Great Data, Not-so-great Experience
Hare’s survey found that while Open Raleigh users liked the data provided, the experience left a lot to be desired. “The public showed a favorable response to the types, frequency of updates, and the quality of the data available, but they resoundingly did not like the interface. Most of the interface comments were about latency and, sometimes, display incompatibility,” he explained. Exacerbating the challenge of building great interfaces is the constantly growing number of web and mobile browsers and platforms.
If the City of Raleigh had adopted an API-first approach, Hare suggests, “we might find that developers, to fit on current and future devices with less work on the part of the City of Raleigh, could modify the data and the exploration widgets that go with it. That would give them a better ability to build great experiences and support new browsers and platforms.”
Machines Versus Humans
If the ultimate goal of government open data initiatives is to ensure that the public has access to government data, it’s important to consider how that data gets to the public. Here, Hare made an important discovery:
“If we look at how data sites are actually used rather than how they are marketed, we start to see some patterns emerge. Open Raleigh has had 1,115,125 human page views in the last 18 months, with a majority of that in the last six months. In October 2014, we peaked at 17,000,000 API calls. In one month, we had 17 times more views [from] machines than humans.
What’s more, as Hare observes, “data consumed by humans has lower reuse value in that it is not being redistributed.” So in theory, API requests are more valuable than human page views because they have a multiplier effect.
API-first is Part of the Answer
A web/mobile-first approach that results in poor user experience and limited data reuse can come with a high cost. Hare points to the poorly received launch of the Minneapolis open data portal as an example. He also calls out CKAN, which launched a data portal for the Ebola crisis that was of limited use on mobile despite the fact that members of one of the groups most likely to benefit from the portal were likely to consume it on mobile and tablet devices.
But is an API-first approach, despite its advantages, really a panacea for open data initiatives? While API-first development is increasingly popular and API-focused development tools are proliferating, designing and implementing high-quality APIs is still far from being a walk in the park. What’s more, great APIs don’t guarantee the creation of the great end-user experiences that ultimately are required for open data initiatives to be successful.
This, however, doesn’t mean that an API-first approach can’t help address some of the shortcomings seen in many open data initiatives. An API-first approach, done right, can help organizations focus on the various use cases they need to support before they jump into building end-user applications. It can also make it easier to iterate and extend functionality without dealing with the technical debt that often builds up around APIs designed to support an existing end-user application.
Finally, an API-first approach gives organizations the ability to engage meaningfully with third-party developers from Day 1. While organizations cannot rely on third parties to make their open data initiatives successful, a good API that makes it easy for external developers to build great open data applications could pave the way to good user experience and more sharing of data.