It's a shame. But having watched a few companies shut down APIs (including my own work at Google) I've learned the hard way that unless an API is central to a company's business success, it's eventually going to become a business problem.
I believe this is the appropriate concern. If your business would critically fail with no alternatives should a supplier back out you have a major problem, this same lesson applies to most any business.
Don't build a business on an API whose backend you cannot change at will.
Same goes for protocols (Facebook Login vs OpenID), format (DOC vs ODT) and data sources (Gracenote vs MusicBrainz). If you cannot replace a service that is behind an API with your own implementation, you must be ready to fold your business the day your provider changes the service terms.
This doesn't surprise me, but it does make me sad because I think it's a short-sighted move that will hurt Netflix in the long run.
Full disclosure: my side-project (which I have woefully neglected of late: http://moviepresto.com) uses the Netflix API to determine if a movie is available on Netflix Instant or as a disc rental and then links accordingly. The title, description, basic info, and background image come from themoviedb.org. Personally, I'd prefer for my "what do I want to watch tonight?" decision start with the set of everything that's been released and then follow to "where is that available?", instead of starting with "what is available to watch on platform X?". My cynical side tells me that Netflix doesn't just want to be the center of the online streaming universe; they want to BE the universe.
Even more sadly, I think Netflix won't even realize what they are missing out on: potential user interface improvements that they could incorporate into their own products, ideas for integration they never would've thought of, potential great hires, etc.
Agreed! I wasn't aware of canistream.it until reading this thread and I'm very impressed with it.
I think if I was aware of that site when I started moviepresto, I wouldn't have built it. But, then again, I wouldn't have learned the things I learned in the process.
It seems like a strategy these days. Start out by giving out API's to get as many other companies to use it and therefore promote your service, then when you're big enough and don't think they are needed anymore, cut them off.
I'm not sure this is the case for Netflix, I think the answer is much simpler : very few people use it and no meaningful project came out of it in the last few years.
Also Netflix will eventually sell or shut down its dvd business. What will remain is a relatively small library of titles available on streaming...
Just today I was talking with someone about integrating Netflix data in to their app, and I almost registered for an API key, but waited until I got home. Then I stopped off, got home late, did some work, and now this. :/
I guess if this is how they run it, then they might revoke access to then-current API-key holders in the future with little warning anyway...
If anyone has ever bothered looking at any Netflix talks / slideshares [1] about APIs, they would have surely seen the various graphs detailing how their API usage started and grew.
TL:DR 3rd party usage of the APIs used to be big, but then became pretty much a statistical irrelevance compared to usage by Netflix's own software / tv apps / etc.
So it would seem the business case to keep developing a 3rd party friendly API is not really there anymore.
I think of APIs as open-source business development, and unless companies get a lot of value out of their apis, they shut them down for the same reason they shut down BD departments: They aren't providing any value.
My best guess: this is to lock out any additional competitors in the set-top game so they can resurrect a Netflix branded set-top. Netflix streaming alongside netflix-vended rentals? I can see it happening.
Is there really any value in a Netflix branded set-top? Every video game console plays Netflix, the new generation of consoles is coming out soon, and a bunch of TVs have Netflix baked in.
I think there was a story recently about how Netflix encodes each video multiple times for the various boxes and television sets. If they had their own box they could be more in control of at least one of those encoding formats.
The Netflix API does not let you create a player. As far as I know Netflix built the player for every device (Ipad, Playstation, Blueray...). If they did not build the player for a device they had to give the device manufacturer a secret API that I am not aware of.
Also, for the curious, their player is all HTML5 driven. They basically compile a browser for each device and build the UI with HTML5.
This could explain why Netflix is pretty much the only streaming provider who has refused to respond to us in regards to getting them on our upcoming media hardware platform. I even sunk as low as tweeting at some of their team to no avail.
Roku shipped their HD1000 "Photobridge" video playing STB several years before Netflix introduced their streaming product. I know it was able to display 1080P MPEG transport streams at the very least.
Netflix forums have been dead for years now... So it is not a surprise.
But still I am sad to see the oData catalog shutting down which mean that my 4 stars iOS/Android/Kindle app will have to be removed from their respective stores.
It is always a trade off when you are relying on API: on one side you can focus solely on the project core values knowing that the underlying data will be provided, on the other side if you build everything including what an API provides you are ending building up a different business.
I'm guessing (and I'll admit I don't know this for sure, feel free to correct me if you do!) that http://instantwatcher.com/ uses it, which is a wonderful data-heavy interface for finding stuff to watch on Netflix Instant. It's much faster and more informative than Netflix's kind of shitty browsing experience.
That'd be my guess too. One of my never executed pet projects was a service that aggregated all of the streaming providers libraries and let me quickly filter between genre, provider and "magic" looking for something I'd wanna watch. Most of the other services don't seem to have netflix level APIs, so it would have taken some trickery to get something approaching a comprehensive catalog for them...
I built http://streamjoy.tv as an abstraction layer above netflix, itunes and amazon and I will attest it took quite some trickery to get something approaching a comprehensive catalog. Even things that should have been simple like using the main python library for Amazon's product api was not simple because I had to rewrite sections of the library that dealt with api throttling limits.
There are gaps in the APIs and though they can be dealt with, it was not always easy or straightforward.
I assume availability sites like http://www.canistream.it/ use their API. I don't know why you wouldn't want to share data that can help you acquire more customers for much cheaper than a lot of other routes for acquiring new customers. Not to mention allows your current customers to browser your catalog in different ways.
That's a pertinent question. For me the loss here isn't so much the present utility of the API, but where they could've taken the API in the future. This seems like a step away from whatever that would've been.
The Plex and XBMC Netflix plugins use the API to browse the available shows. I guess they'll be okay since they're allowing existing clients to continue access, but any future plugins for other platforms are DOA.
I'm guessing most of the third party sites with Netflix functionality are manually curated or just use basic title search. There's just no good way to throw together a list on the fly based on custom criteria. The OData catalog was much more flexible, but they never supported it or kept the info up to date.
Most of the main API team left the company ages ago. It's been dying on the vine for months. At least it's official now.
I use the OData interface to power streamingcriterions.com, which is totally niche but still get a couple hundred hits a day. I built it to scratch my own itch, but I guess it'll stop working pretty shortly. Bummer.
Had a similar project based on OData called qwikstant.com, by no means a hit, but still trafficked. It's depressing to have to shutter it.. As I was developing I did notice that the OData DB was always slightly behind and the api forums were a ghost town - guess I should have seen it coming, but I had an itch. Got burned when google shut off services before as well, pretty sure I'm finished with free corporate APIs at this point, experimentation and one-offs aside.
There are a lot of different types of APIs (partner, SaaS, internal/mobile, infrastructure, etc), many of which you can use as a part of building a business.
Never build a business freeloading off another business. The social and consumer API providers are realizing that their APIs don't drive value to their core business objectives (selling subscriptions or ads). APIs are a means to an end. The end has to benefit both sides. Don't blame the means for faulty ends.
One is a service, the "aS" in PaaS, SaaS, and many others, where what you are getting is programmatic access to the thing people want to sell you anyways. A service might be very valuable, but it's probably replaceable. If someone is geolocating IPs for you, hosting images for you, handling blog comments for you, this is all stuff someone else could do for you if your first-choice API turns into yet another /dev/null.
The other kind of API is access to specific content and/or networks. This is a whole different ball of wax, and I would be wary of doing anything significant with an API that is only valuable because of the value of the data that is coming over it. You have to ask yourself very carefully why they are giving you access. Most likely it is because they think you will drive growth to them. Once that motivation is gone because they have reached scale, they will stop treating you as valuable, and start to see all the value you generate as value that is not being sent their way: they will start rent-seeking.
Basically, ask yourself: if some API that you use were to close up shop, would your company no longer have an existential purpose? If you want to give people directions to a brick-and-mortar store, and Google Maps closed itself off tomorrow, would your company cease to exist? Hopefully the answer is no, you would just have to spend some resources and switch to someone else or build it yourself.
