Home Daniel Jacobson of Netflix on the API with an Audience

Daniel Jacobson of Netflix on the API with an Audience

Alexia Tsotsis, who writes for TechCrunch, had this advice on Twitter earlier today: “Good tech blogger rule of thumb: Avoid using ‘API’ in headlines when/if you can.” Usually, I’m all thumbs myself, but I can’t find this particular rule on them anywhere. I suppose I’m not a blogger after all.

Or perhaps I just know my audience. The first rule of communication, as I have taught and been taught (both quite repeatedly, and often) is, “Know your audience.” The API has become the principal communications tool of any company that does business digitally. Therefore, professes Netflix Director of Engineering Daniel Jacobson, when designing your API, you should identify, evaluate, and serve its audience just like with any other communications tool.

So naturally, like anyone who’s heard the “Audience” axiom for the very first time, I asked the principal builder of Netflix’ new, corporate-wide API, the veteran developer of NPR’s API used in Infinite Radio, and the co-author of APIs: A Strategy Guide, what in the world he possibly means by that. In the third and final part of our continuing interview, part 2 of which was published in RWW last week, Jacobson defines two audiences: the public who uses a company’s servers, and the company itself. And in contrast to many developers on the public stage today, he believes the evolution of your API begins internally.

“The most important decision you can make about an API program is, who is or are your key audience that you need to focus on?” states Jacobson. “Because once you’ve focused on the problem there, you get all kinds of other decisions that fall into place.”

One-Third of the Traffic Isn’t Half the Picture

The more common API project nowadays is based around a Web app or Web site, for what he calls the public use case. Oftentimes this is built as a shell around the business’ existing services, effectively codifying the interactions that already take place every day by way of ordinary Web forms and the Submit button. A much more powerful case for API development – the foundation of Jacobson’s entire philosophy – is the internal use case. This is where the business codifies the transactions that constitute everyday business.

Here is where Jacobson makes one of the most shocking revelations of all: Even though his service has been estimated to comprise as much as one-third of all downstream traffic in North America, the volume of API calls to Netflix servers whose source is the general public – someone out there with an Xbox 360 or a Windows Media Server or a Web browser connected to Netflix streaming video – is only about 10%.

“Most companies are exposed to these concepts of open APIs, and that’s what gets them excited,” he says. “It’s about use cases, Twitter, Facebook, and whatever else changes business focus around the public case. So a lot of companies will take that concept of a public API, create a program around that, start thinking about office APIs, and then realize the opportunity that the private APIs gives them – multiple platforms, local apps… And once that happens, there’s a transition point where a lot of these companies will say, ‘Wow, I can really see a lot more power out of the internal use case.’ And just like at Netflix, it will change your thinking about how you want to strategize your office.”

As the APIs book states in Chapter 4, “The value chain starts with business assets, something that a business wants to allow others to use. Business assets can range from a product catalog to geospatial maps to Twitter posts to airline status information to services that allow products in the physical world to be controlled by virtual services such as payment systems. If there is nothing of value in the business assets, the API won’t succeed.”

The API’s job, the book goes on to explain, is to expose these business assets in a secure and manageable fashion. Once that’s feasible, developers are enabled to build applications around the API that makes these assets available. In the end, the app is developed around the assets, not the API. And if the API doesn’t efficiently represent these assets, the app will likely fall apart, and the business’ API strategy will fail.

Can an API Be Made ‘Turnkey?’

But let’s face it, isn’t there some type of cloud-based service or outsourcing operation or a set of templates you can just plug in and build an API in three easy steps? You know, an “API wizard?” After all, aren’t most RESTful architectures basically two-thirds the same?

You could almost hear Dan Jacobson’s grimace through the telephone wire. “A lot of people think about APIs as open APIs,” he responded. “And we [the authors of the APIs book] really wanted to put an emphasis on thinking about this as a business opportunity, and the internal, private use cases of interacting with your partners or your internal development teams. When you think about it in that context, outsourcing it to a company and just flipping a switch and turning something on isn’t going to have all that business sensitivity baked into it.

“I’ve said it before, you need to bake your business DNA into your APIs,” he emphasized. “If you don’t do that, then you have this service that’s not really filled with what your company is going for.”

Netflix, he admits, is actually among the companies that have had to shift their API strategy. It’s redeveloping the current Netflix Public API for a greater emphasis on the use cases that the general public will never see. “In Netflix’ case, the business opportunity is independent from our ability to reach tens of millions of users, and get them into streaming on their devices and consuming our content,” the lead engineer tells RWW. “That’s the opportunity we are trying to pursue, and the API helps facilitate that, makes it faster, easier. And to the extent we can improve our strategy on building and improving these APIs, we can better improve our ability to satisfy our business goals.”

The book projects a metaphor of APIs in the form of an iceberg. “A small part of what you see – which represents the public API – is above water, highly visible, but is also such a small percentage of the total mass. This huge mass underneath the water that you can’t see, the private API, is the biggest part of the whole opportunity. I think it’s a great visual around the way things are evolving in this space.”

About ReadWrite’s Editorial Process

The ReadWrite Editorial policy involves closely monitoring the tech industry for major developments, new product launches, AI breakthroughs, video game releases and other newsworthy events. Editors assign relevant stories to staff writers or freelance contributors with expertise in each particular topic area. Before publication, articles go through a rigorous round of editing for accuracy, clarity, and to ensure adherence to ReadWrite's style guidelines.

Get the biggest tech headlines of the day delivered to your inbox

    By signing up, you agree to our Terms and Privacy Policy. Unsubscribe anytime.

    Tech News

    Explore the latest in tech with our Tech News. We cut through the noise for concise, relevant updates, keeping you informed about the rapidly evolving tech landscape with curated content that separates signal from noise.

    In-Depth Tech Stories

    Explore tech impact in In-Depth Stories. Narrative data journalism offers comprehensive analyses, revealing stories behind data. Understand industry trends for a deeper perspective on tech's intricate relationships with society.

    Expert Reviews

    Empower decisions with Expert Reviews, merging industry expertise and insightful analysis. Delve into tech intricacies, get the best deals, and stay ahead with our trustworthy guide to navigating the ever-changing tech market.