Redesigning the Netflix API: No Versions, Many Endpoints

Adam DuVander, July 28th, 2011

NetflixWhen 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.

Both comments and pings are currently closed.

5 Responses to “Redesigning the Netflix API: No Versions, Many Endpoints”

July 29th, 2011
at 5:20 am
Comment by: Redesigning the Netflix API: No Versions, Many Endpoints – ProgrammableWeb (blog) | HotTopicSource

[...] ProgrammableWeb (blog) [...]

July 29th, 2011
at 12:30 pm
Comment by: State of Technology #18 « Dr Data's Blog

[...] #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 [...]

August 1st, 2011
at 10:59 am
Comment by: monsur

It looks like you are pointing to the slides from Netflix’ Mashery talk; here are the slides from OSCON:

August 1st, 2011
at 8:49 pm
Comment by: Will REST Accommodate Our Needs in the Future? | API Evangelist

[...] reading Adams post from last week, “Redesigning the Netflix API: No Versions, Many Endpoints”, and looking through the slides from Daniel Jacobson’s Netflix talk at OSCON again, I [...]

August 2nd, 2011
at 3:46 am
Comment by: Jerome Louvel

It would be interesting to know if NetFlix consider using HTTP content negotiation to adjust the formats based on the type of device.

Follow the PW team on Twitter

APIs, mashups and code. Because the world's your programmable oyster.

John Musser
Founder, ProgrammableWeb

Adam DuVander
Executive Editor, ProgrammableWeb. Author, Map Scripting 101. Lover, APIs.