/// Got Structure? The Basics of APIs for Content
here is a big structural change afoot in the world of content. The era of crafting singular publications — and even websites — is giving way to the production of content streams. Not everything needs to be an app, but more and more things will be.
As readers get used to having more and more control over how they consume your content, you, in turn, will have to become more flexible in how you supply it to them. This is where APIs, or Application Program Interfaces, come in. In general terms, an API is a set of highly programmatic web addresses that can be used to access granular content and functionality from a site (often within a permission structure.) They are rapidly replacing RSS feeds as the primary method of distributing content online.
What RSS feeds have been to websites and blogs, APIs are to apps, and there are significant differences between the two. RSS feeds are XML streams of metadata about the new content on your site. APIs can not only push out new content, but also enable other sites and apps to query for specific content and even specific components of that content.
The lever for the rise of the API is the exploding popularity of mobile devices. Not only are there new screen formats emerging constantly, but usage levels, particularly on iOS devices, keep exceeding all expectations. One of the big surprises is how much reading is happening on these small screens.
The proliferation of mobile devices with all their many pixel dimensions requires publishers to undertake what user experience consultant Karen McGrane refers to as the “separation of content from form.” In her new book, Content Strategy for Mobile, she argues that the key to producing content for multiple platforms is to create a consistent structure that is not tied to how the content is presented. So, for example, headings should be given a clear hierarchy (<H1>, <H2>, etc.) but the size, font and color should not be specified in the content management system. It is assumed that each view of that content, whether on the publisher’s own site or a third party’s, will apply style for each given view. The content must be allowed to adapt to each new context because all possible contexts cannot be reliably anticipated.
In her public lectures, McGrane often uses NPR as a case study, because she considers it “such a beautiful and easily understood example of the value of using adaptive content.” From the launch of its public API in 2008 until its expansion to its current form in 2010, NPR went from “only a few hundred thousand requests per month to more than 40M,” according to a presentation at the O’Reilly Open Source Convention. As a radio broadcaster, its primary content type is audio files, but in its current API, each story has been structured with metadata to also include headlines and links of different lengths, summaries, photos, video files and full transcripts. And all of these elements are managed through a single backend for the content producers and can be accessed, in a programmatic way through the API.
As a non-profit, NPR’s goals are different than traditional publishers that need to monetize their content and have to confront the thorny issue of how to best limit the accessibility of their products. By making its content easier to use, both for its own internal products as well as those of third-parties, NPR has exponentially increased the reach of its stories. In this way, its lessons are particularly relevant for brand publishers and content marketers whose motivations are also tied to spreading their stories without the need to get paid for them.
In order to leverage the most value from their content, publishers, business owners and institutions of all kinds need to understand that they are no longer in the magazine business or the catalog business or even the public relations business, but in the business of making their content easier to find, select and incorporate into the wider digital world.