The New York Times is one of the most venerable and well-known newspapers in the world. Despite its long history, the Times faces significant disruptive pressure from the competitive media environment.
Proliferating sources of content, changing expectations of information consumers, and shifting sources of revenue have forced the New York Times to reconsider how it creates and distributes content.
Open APIs are an important part of that new distribution strategy. Using APIs, the Times is increasing the value of its content by making it available to developers to build applications that can drive broader distribution.
For episode 161 of the CXOTALK series of conversations with innovators, I spoke with Scott Feinberg, API Architect at The New York Times. Scott is the person responsible for designing APIs used at The Times.
Here is an edited excerpt from our conversation. In this segment, Scott explains why APIs matter to The Times and describes some of the issues involved with creating those APIs:
Your APIs are available free to the public. How are they used?
A lot of the people who use them are researchers trying to find patterns. We've got 165 years of content to research how the spoken word has changed or which stories have been popular between 1940 and 1970, for example.
Others want all the articles about a certain topic, or use our APIs with IFTTT (If This Then That), integrating with us using point and click. They can have it go into their Evernote. Whatever they want to interact with our content. Public libraries use our Best Seller list to decide programmatically which books to buy.
There's been a lot of interesting uses, and we're always looking to learn from our users and put those experiences back into our main product.
How do APIs support the mission of The New York Times?
The core mission of The Times is to enhance society by creating, collecting, and distributing high-quality content. Most of the time, APIs are used to distribute that great content; without them, it would be very hard for us to provide information in the different places people want it. We want to inform and give you the news and the information in whatever way makes the most sense for you.
For example, our cooking website started with the realization that we have 17,000 recipes dating back to the 1800s. Because we have a service that already stored all that content, were able to build and reuse it.
Cooking was a hard API to build. Recipes are an incredibly hard domain to model because you have unlimited sizes, like a dash of sugar. How do you represent that when it's a metric of size, but at the same time you can have two dashes?
Representing food and recipes is hard, so we push people to spend time upfront designing the interfaces, thinking about what a recipe looks like. Working with domain experts in recipes gives developers a greater understanding of the content and how to add new ways to present recipes, sizes, measurements and things like that.
How do you encourage adoption of your data and content?
You can't be stingy; you have to give it out.
When we launched our developer portal there were a lot of questions like, "Are people going to steal our data?" Questions like that. Just give it away. You don't have to give it all, but don't be stingy.
Eventually, you're going to find passionate people who are interested in using your data in new ways. Enable your users to build the experience they want.