Redesigning the Netflix API: No Versions, Many Endpoints | Hacker News Reader

Redesigning the Netflix API: No Versions, Many Endpoints

blog.programmableweb.com

The main problem with versioning the API is that many of the hardware partners cannot easily update their API interface and this leads to a 'legacy' approach to maintaining the API. Having had a background in enterprise software, I can tell you how frustrating this can be.

If the NetFlix API had versions, you can quickly see how this would proliferate out of control. Devices from each class (assuming the versioning was done on a time release basis) would probably need to be supported for about 10 years (the expected lifetime of the device). This would mean NetFlix would end up supporting over a dozen versions just to keep its hardware partners happy.

Another solution would be to insist that all hardware accessing the API must be capable of being flash updated. This would allow NetFlix to insist on supporting each API version for only a limited amount of time (sufficient for the hardware to be updated just like any other software service).

NetFlix basically has the choice of dealing with the complexity internally or forcing the ecosystem to suck up the pain. Their choice will be driven more by business concerns (who needs who more in the relationship, what are each parties' options) than technical (what can we do given how much money we are willing to throw at the problem).

I think it's a good idea to have a unified API and various compatibility layers, but...

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

... what's wrong with a simple n=count parameter in this case?

The "in multiple categories" part is pretty key here. What he's talking about is being able to combine the results from multiple queries, not simply returning more results in a page for a given query.

So: why not a Batch API like FB's?

I've always thought APIs should try to avoid versioning. It's usually pretty easy to enhance APIs in a backwards-compatible manner. It also forces smarter design and restraint. Existing users rarely update integrations until they are forced and then it is a major pain just to stay in place.

If you don't version, you can only add to an API. You cannot change anything meaningful (or as simple as renaming a field). You wind up with APIs with multiple ways of getting the same or similar data in order to avoid breaking backwards compatibility, which leads to bloated, confusing APIs.

> You cannot change anything meaningful Sure you can. I think it's great that a lack of versioning discourages things like renaming a field. It's with versioning where you wind up with...multiple versions.

The problem with this is when you do something stupid. Let's say your GetFrobz interface is missing something, or requires a parameter it doesn't really need, or just stupidly keeps state around to provide a feature that's not important. If you don't have versioning, but want to replace this, you have to call it something different.

So now you have GetFrobz and FetchFrobz and you need to tell everyone to not use GetFrobz in new applications.

This really does happen. The first example that comes to mind: is POSIX random numbers (rand,random,drand48), but there are loads of others anywhere that backwards compatibility is deemed important.

Reply on news.ycombinator.com