
Redesigning the Netflix API: No Versions, Many Endpoints - apievangelist
http://blog.programmableweb.com/2011/07/28/redesigning-the-netflix-api-no-versions-many-endpoints/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ProgrammableWeb+%28ProgrammableWeb%3A+Blog%29
======
takinola
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).

------
inportb
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?

~~~
obeattie
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.

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

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

~~~
pgr0ss
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.

~~~
pbreit
> 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.

