The White House API Standards and the Ancestry of Government API Guidelines

Note: This is somewhat technical and focused on APIs, but may also be of interest to anyone who cares about how conventions and trends for digital government spread.

I’m in the middle of a research project on government APIs, and as I’ve read more and more examples of API guidelines from governments across the world, it’s struck me how so many of them can trace their roots back to the White House API Standards. Even if I haven’t found evidence of direct lineage from the White House standards to a given API playbook, that playbook usually at least cites the White House repo as a resource or example for further reading.

Origins of the White House API Standards

In 2011, President Obama issued an executive order mandating that US federal agencies had to make web APIs. I can imagine that things got chaotic pretty quickly, with competing conventions struggling for dominance like tortoises crawling on top each other for the sunniest spot on the rock, because the following year someone had the good idea of creating a document of API standards for at least the White House APIs to adhere to.

The White House API Standards repository on GitHub was created on Dec 19, 2012, with a first commit whose message and content was some pretty impressive ASCII art:

The committer is Bryan Hirsch, tech lead at New Media Technologies at the White House at the time. I found this sweet slide deck that he and Leigh Heyman, Director of New Media Technologies at the White House, used to explain the thinking behind their new standards, plus an article about and video of the talk.

The tl;dr is that they created the API standards after working on the “We the People” petition website and related API, in order to make the underlying data concepts easier for non-developers to understand as well as maintain and encourage API best practices over time at the White House and maybe beyond. That beyond definitely happened.

Before I get into that, I think it’s worth documenting here the influences on the White House API Standards:

• Designing HTTP Interfaces and RESTful Web Services
• API Facade Pattern, by Brian Mulloy, Apigee
• Web API Design, by Brian Mulloy, Apigee
• Fielding’s Dissertation on REST

It’s also worth noting that the White House petition project was built in Drupal, and these standards include Drupal-specific resources and one of the main influences is a talk from a Drupal conference. The standards also still include JSONP examples, although that technology is outdated, insecure, and not generally recommended anymore.

The offspring and third cousins twice removed of the White House API Standards

To trace the family tree that sprung from the White House API guidelines, I started with the GitHub repository’s forks. There are 654 forks, which means that the repo has been copied and potentially extended or used as a base for other projects 654 times. It has 2,621 stars, meaning that many unique users on Github wanted to register their interest in the project. 215 users are watching it, even though the last activity was 4 years ago.

The following governments have made direct forks of the repo:

• City of Philadelphia
• State of Massachussetts
• US Dept of Labor
• UK Gov Digital Service

Admittedly, a fork doesn’t automatically mean use, but in some of these cases the forking organization has clearly used and updated the standards.

Other government agencies cite these guidelines as their origin, although I can’t find a direct GitHub fork or commit trail:

• 18F: Source by forking the White House’s repo.
• Australian Digital Transformation Office: Source
• Finland: Source
• El salvador: Source

The fact that 18F (and subsequently the General Services Administration), the Australian Digital Transformation Office, and the UK Government Digital Service all have API guidelines that either directly originate from the WH standards or were influenced by them is pretty significant, because all three of these organizations have been hugely influential in digital government and government API strategy and implementation.

And the influence of this repo don’t stop with the public sector. Plenty of private sector and nonprofit organizations such as Code for America brigades have forked the repo or cited it as an example or influence, including Microsoft and IBM Watson

Most of this was uncovered through browsing and text searching on Github as well as on DuckDuckGo. You could explore this more rigorously with some comparative textual analysis of government API guidelines out there that may not reference the White House repo, but I’m not sure if it’s worth going that far. APIs have gotten more ubiquitous and as more and more governments (and companies) have started implementing API programs, their API conventions have matured and evolved past the White House API standards to include things like design thinking for API product strategy and more detailed recommendations on other aspects of API lifecycle such as security and discovery.

Despite that, it’s interesting to see how much impact these standards have had. As I continue with my research, I’ll probably be able to further trace lines back to 18F, UK Government Digital Service, and Australia, showing the impact that any single organization can have on this tightknit landscape.