NPR’s API: Create Once, Publish Everywhere (COPE)

Loose note from the SXSW 2011 session: NPR’s API: Create Once, Publish Everywhere (COPE)

Over the last year, NPR’s total page view growth has increased by more than 80%. How did we get that much growth? Our API. The NPR API went live to the public in July 2008 and was designed with the philosophy of Create Once, Publish Everywhere (COPE). Through COPE, NPR has been able to quickly and efficiently distribute content to virtually anywhere, including NPR stations, partners and the general public. The biggest impact that the API has made, however, is with our mobile strategy. The API has enabled NPR product owners to build specialized apps on a wide range of platforms and devices, liberating them from being dependent on custom development to access the content. Through this process, we built our iPhone and iPad apps, mobile sites, open sourced Android app and HTML5 site, some of which were turned around in a matter of weeks! Delivering more than one billion stories a month and serving thousands of product owners, partners, stations and public users, the API has clearly become the centerpiece of the NPR’s digital media and mobile strategy. In this session, you will learn all about the guts of this mission-critical system (from a technical and business perspective), our publishing processes, our moblie strategy and other related aspects of our digital distribution approach.

Zach Brand
Sr Dir Technology
NPR

All Things Considered, Morning Edition are the most popular radio shows in U.S. Member stations have a weekly audience of 35 million. NPR site has a lot of digital content not available elsewhere.

Why you should care about COPE:

Flexible content, CrossMedia, TransMedia

You want the same content in a lot of different places.

TransMedia = One story with many facets, told in different mediums.

You get to Flexible Content by embracing COPE. NPR doubled their content and audience by embracing COPE.

Getting found is getting harder – more than a billion web sites now.

Principles:

1) Don’t try to build one gigantic system to rule them all. You probably spent between $1 and $10 million on your CMS and ended up not liking it. Better to build an API and then publishing systems on top of it.

2) COPE drives all other architeectural decisions. REalized at NPR with the NPR news API

3) Content Management Tools and Presentation Layers should be two separate beasts.

4) Understand Your Atom. Story is teh Atom for NPR. Stories contain “Assets” (text. audio, video, images, etc.). Stories belong to “Lists”

5) It is better to be incomplete than inaccurate. You don’t know how content is going to be used so you must have a great deal of trust in quality of your content.

History:

1997 – No CMS, every page hand-crafted HTML. Very difficult to manage.
2003 – Beginnings of a CMS
2005 – Much better integration, much better design. But now a ton of resources refashioning stories for each implementation (display type)
2008 – First media company to launch a public API.

Target audiences
	- Ourselves
	- Stations are actually our customers
	- Non-station business partners
	- We're a public service mission, so this stuff is available to the public
	
Launch expectations:
	- Improve efficiencies
	- Partner integration will be easier
	
Life of a Flexible Story:
	- CMS --> API --> Various Presentation Layers

API is a giant XML repository
Registration key needed to consume API content.
Highly normalized data management layer is in Java/JSP Struts
Normalized data rendered out to a flattened data management layer (i.e. not great for querying against)
API layer – a bunch of parsing – supersets of XML data – emits simplified XML.
Presentation layers may actually be separate CMSs at member stations.

Just launching the API didn’t double the traffic – it was building cool tools on top of the API that did that.

Lessons:

– Flexible content is design agnostic
– Content and technology are intextricably linked. Good tools, good people.
– Be smart about managing content. If you have a link to a Flash anim., and you consume on an iPad, then what?
– Pictures – need to be able to automatically call the right version (size) for the platform being used. They built an image cropping tool central to the CMS that lets you crop same image at various aspect ratios.
– Team structure should recognize the Tech/Conent link. Editors, tech, producers must meet in the same room regularly
– It’s an investment. You have to spend time/money not just on building the API.
– It does drive the business forward. NPR dramtically improved development efficiencies. NPR’s mobile strategy totally took off. Some sophisticated stations have used the API (but not all). Partner integration has been much easier. API has facilitated business develoment opportunites. The public has done some interesting things. We launched our first iPhone app, but we didn’t know about it – a member of the public built and released it.
– People are are interested/inspired by your examples.
– You WILL eat your own dog food. Public request the more API keys, but NPR is the biggest consumer of it.
– Our architecture (2008) struggled with change.

- Lame excuses why not:
	- People can steal your content
	- Leadership doesn't underst what an API is/ Benefits
	- API doesn't result in new product for  customers
	- You'll have to replace CMS
	- ...
There's a Controller module in COPE that manages queries and output formats.

Results of re-done API:
	- Response time is 22% faster
	- Eliminated many slightly inaccurate returns
	- Faster development on the API
	- Cleaner separation of output formats
	- No more use of Xpath queries
	- Easier ramp up for new developers
	
What's Coming

	- Collections and Lists
	- Image crops
	- New output types are easier (including plists)
	- More ingestion partners - and a public media platform

Stations themselves produce a lot of content. If they deliver content back to NPR, can they control how it’s redistributed?

Public Media Platform is coming – will be “super cool.”