Netflix, Philips, and the fragility of APIs

Update: Either Philips or Netflix has now fixed the problem described below (2014-03-29).

Philips 4000 series TV

I bought an inexpensive 29″ Philips 4000 series TV for the basement, and its built-in Netflix app isn’t working.

Why doesn’t Netflix work on my TV?

Time to head for the online support chats. What does Philips have to say?

Unfortunately at this time Netflix is not working on any of our units at this time. Netflix processed an update without informing our company. With all smart TVs, when an app maker processes an update, their API will change. This essentially locks our entire unit out of Netflix until we can process a software update for our units by individual model. We are working on this issue as fast as possible. Unfortunately there is no ETA on the update.

OK, then what does Netflix have to say?

I just checked on this issue and yes indeed there is an issue. Our tech geeks over here are working on the matter and we don’t have an ETA as suggested by the guys at Phillips for sure, but no worries with the help of them I can assure you that it will be fixed, 2 heads are better than 1 huh…

Thanks to both companies for giving me honest answers fast. So it just turns out that Netflix had one idea of the API, Philips had another, there was no management/communication mechanism before deployment, and the consumer experience broke.

Approaching O(n²) complexity

This is a good example of a growing systemic problem in the world of API-based integration, and one that will apply far beyond just consumer devices: ever since the Web 2.0 fad of the past decade, people have pushed the idea of APIs as a silver bullet for integrating information and services from separate organisations. APIs are a huge step forward from scraping, but if you have m service providers with APIs and n service consumers using the API, how do you keep the m*n dependencies all in sync? What happens when your business depends on an API whose terms of use change? As shown above, change management is not easy, even for big, consumer-facing companies (and especially not for someone like Netflix, who tries to work on so many different devices from so many companies).

Closing rant

While we’re on the topic of APIs, please don’t use the nonsense term “RESTful API” — the whole point of REST is that it’s not an API (or rather, that its API is HTTP, and most of the semantic burden gets switched from API to payload).

This entry was posted in Integration, REST. Bookmark the permalink.

10 Responses to Netflix, Philips, and the fragility of APIs

  1. John Cowan says:

    One of my jobs at Google was to help product teams to understand that while they could change their web UI at will, they had to have a deprecation policy for their APIs, with lifetimes measured in years, not months or days.

    Restful API considered harmful: Oh pfffft. All lions are made out of meat, but that doesn’t make the phrase stone lion self-contradictory or useless. A RESTful API has some of the properties of an API as a stone lion has some of the properties of a lion, which suffices.

    • “Nonsense term” might have been too harsh, but when you have a GET request that returns a CSV, XML, or JSON resource, I believe that the term “API” causes more confusion than clarity, and encourages less-experienced developers to wander into overly-complicated morasses like data binding.

  2. “the whole point of REST is that it’s not an API (or rather, that its API is HTTP, and most of the semantic burden gets switched from API to payload).”

    LOL, this must be the funniest thing yet I’ve read in 2014.

  3. Dallas Gutauckis says:

    This is why it’s smart of Netflix to be moving in the direction of self-updating clients (HTML clients written in C that load a Netflix URL on each open). This way, you don’t have to deal with TVs or other devices that never get updates. You simply update the page that is loaded to work with the new API.

  4. Peter Rushforth says:

    I think the term REST API may best suit that category of API that are provided by the browser, based on the media type, i.e. the DOM and friends.

  5. Andrew Doble says:

    One pattern used in application integration to handle the n*m interface problem is to use a canonical data model. Basically this means a standardization of at least the data that is passed between the different applications. In a web API context this implies a standardization at an industry level, something that I don’t think is really happening at the moment.
    Note that the other problem is a standardization of the operations that can be performed. With a REST style this problem has been somewhat minimized due to a restricted set of operations, i.e. the HTTP verbs.

    • Exactly (for REST and industry standards). Standards are really, really hard, so you need a big payoff for the person-decades invested in establishing one, but consumer Internet TV devices may have reached that point.

  6. AzraelKans says:

    Just to let you know this is still an outgoing problem. I just bought this TV unaware of this problem, and Netflix still has loading issues, I cant watch a single complete video, because Netflix will disconnect a few seconds after it starts.

  7. sheila says:

    they still have not fixed the problem… netflix and philips are useless at this point

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s