Redesigning the Netflix API: No Versions, Many Endpoints

Adam DuVander
Jul. 28 2011, 12:00AM EDT

When video rental and streaming company Netflix released its Netflix API, it was meant to support its DVD-by-mail business. In the time since the Netflix API was released, the business has shifted to streaming instant video, from hundreds of devices. Meanwhile, the Netflix API hasn't changed much and it's time for a redesign, according to Netflix's Daniel Jacobson in his talk at OSCon Wednesday. Jacobson's talk offers examples of how the next iteration might look, including doing away with versions, but creating unique endpoints for each partner's application.

Most REST APIs are designed to support multiple apps with a generic response. Netflix's problem, which has led to its many billions of API requests, is that different devices have different needs. The iPhone may only show a few recommendations, while a TV may have several rows of movie suggestions in multiple categories. Yet, if those two devices are calling the same API, it will take perhaps a dozen requests for the TV just to load the Netflix home screen.

Once that TV or other device using the Netflix API is out in the wild, Netflix needs to support the API for some time, because it can't always force an update of software running on a sprawling number of hardware devices. That makes changing the API very difficult. You'd think the answer would be versioning, but Jacobson thinks the opposite.

Rather than versioning its API, Netflix plans to offer unique endpoints for each device. Each is a sort of abstraction layer that speaks to a central Netflix API. By using different endpoints, Netflix also solves the exploding requests problem. Each of those endpoints can be optimized to only return the data needed by that particular device.

Jacobson explains the approach in his slides embedded below.

It's not an approach that every API can use, though Jacobson said many providers may realize it once their platforms mature. With Netflix focusing on its streaming business, it's clear this strategy is a way to improve user experiences while separating those optimizations from the main API. This pseudo internal use is where Jacobson expects the API landscape to see the most growth.

You can see more of Jacobson's thoughts on APIs in his series of guest posts on ProgrammableWeb from his time at NPR:

We also covered Jacobson's move to Netflix in September.

Adam DuVander -- Adam heads developer relations at Orchestrate, a database-as-a-service company. He's spent many years analyzing APIs and developer tools. Previously he worked at SendGrid, edited ProgrammableWeb and wrote for Wired and Webmonkey. Adam is also the author of mapping API cookbook Map Scripting 101.

Comments

Comments(5)

[...] #architecture – How would you design your service API to serve 3 end-points – Chrome, iPad and Android? How about 100? This is how Netflix re-designed its API with billions of API requests ending in more than 100 devices [...]