Any API key is just that. A key. A key to the stairs up the shoulders of giants. A place that can be shrugged. From which one can fall. But also from which one can see further. Further even than the sacred concept of "ownership".
I too am very disappointed and agree with the other commenter who said they are big enough that they don't have to worry about closing it. When I realized I wanted an API key they had already stopped handing them out, and now the axe falls again. I don't argue it's not within their right, it's just sad.
I have upwards of 1200 graded movies in another service that I used for a long time and that has a public API. Nowadays, I use trakt.tv a lot (and pay for it, because I really want it to be around, like I pay for Netflix and Spotify) and they also have a public API that I can use to write a tool and migrate/sync my movie grades there. Netflix' recommendation engine could have learned more about me in 5 seconds than it will in 5 years, and any grades I put into Netflix will never leave it.
Yes, I know I'm an edge case. Yes, I know it doesn't make business sense to cater to me. I still need to gripe a bit.
I have a custom app for managing my music too that uses the Spotify C library (wrapped in Go). I love that I was able to do that, and the day Spotify EOLs that library (and doesn't provide an alternative) is probably the day I leave their service.
Enough ranted. Sorry. I just like to take my data with me when I go.
I agree it is stupid that data you enter into a service, which you cannot know if it will remain (and that means every service), you can't extract to do with it what you want (log it yourself). It just gives me a better feeling if I can extract my netflix watching habbits and ratings for my own usage instead of relying on their ways (but their way isn't bad).
Also I just recently tried Mopidy again, a year ago it would crash a lot and time outs and stuff, but now I have it running as my main MPD with MPDroid on my phone and also Mopidy-Spotify. It is really awesome! I can just use my own keyboard shortcuts again to prev/play/pause/next again which I always found a burden in the spotify client.
I'm with you on that Spotify C library, it would suck so much if they would EOL it without replacement.
They might get some flack for suddenly being less open about data. Adding a [download my ratings] button on the account page seems much less ambitious than maintaining an API so that might be on the table in the future.
> To better focus our efforts and to align them with the needs of our global member base, we will be retiring the public API program
What a sad statement, there is no need for this corporate-drone talk. "We're shutting it down because it doesn't make us money, and we think we will be better off being a closed platform" would have ringed much better, not necessarily in these words. Honesty is always appreciated.
I disagree. In my time on Hacker News I've rarely seen people react positively to casual language in a press release unless the news itself is good/respectable (e.g. an apology, an announcement for some beneficial initiative, etc). I think they're better off using the language they used, and forcing the savvy to read between the lines.
I agree but wouldn't say it is anything specific to Hacker News. Honesty and plain language for these types of releases is generally only appreciated when there is an ability to work in a self-deprecating angle, or cast the message into the form of a reasonable request for forgiveness (which is, essentially, asking people a favor). eg:
"Sorry, we fucked up by doing this, that and the other thing. We will try not to fuck up again. Please bear with us."
People like that.
"We're taking away access to something you might use and like because we don't make any money from it."
People don't like that. Since the nature of the message isn't in-line with asking for forgiveness or asking for a favor (which people love, see: the Ben Franklin effect), the bluntness reads like "Fuck you, because we can".
Well, nobody wants to be the bearer of bad news. Being honest about these things usually means it will be seen as bad news. So you try to shift the focus to make it seem like the opponents (customer in this case) need was the trigger instead. Keeping some of the applications was a nice touch in addition to, apparently, announcing some kind of partner program.
They should read through the http status code list again though. 404 means that the server is currently unable to find the resource requested. 410 means that the resource is gone and never expected to return. Sure, I'm being picky but if they are refocusing their development efforts it doesn't seem to much to ask that they read up on http status codes and use them correctly.
> What a sad statement, there is no need for this corporate-drone talk.
I've always wondered if PR-types think that people "buy" stuff like this. It's somewhat expected from "old" companies but you would think a company like Netflix would be different.
But it does make them money, just indirectly (users using the apps to enjoy the service more). Look at those apps they listed, none would exist without the api, meaning their users wouldn't be using them, and many continue their subscription to netflix because they exist.
How many users would that total to? How much money?
Additionally, it's cheap marketing and cheap growth. Both good things for a subscription model company.
Taking the api offline is short term thinking and might hint it's time to sell.
There is something here that I really don't understand.
Why would they want to shut it down?
With something like Twitter, I get it. In order to make money off their customers' use of Twitter's free service, they need to be in control of the customers' experience (so they can do things like show ads). So they pulled this intentional bait-and-switch where they screwed over the independent developers who had made Twitter successful in the first place, but they did it because they needed to in order to make their profits.
The Netflix API story is different. First of all, APIs were always an additional offering: Netflix was grown on the backs of their mail-order business and third party apps that could just as well have been done via partnerships instead of open APIs. So they're at least not screwing over the one who brought them to the dance.
But the APIs have been a source of good will from the developer community (probably all out of proportion to the number of actual tools built using them). And the APIs are not harming Netflix's income stream in any way. (They might, in a tiny way, be helping, but I accept that this effect is negligible.) So where is the motivation to retire them?
Does it really cost so much to maintain the APIs? After all, they need to maintain them for Instant Watcher, Fanhattan, Yidio, NextGuide, Flixster, Can I Stream It?, FeedFliks, and Instant Watch Browser for Netflix. So it's not like they'll save the cost of keeping the APIs running. And I don't see how this can be about the cost of managing communications with the public -- if, instead of announcing that the APIs were now closing down, Netflix had announced that the primary support channel was now a public forum where users could help each other I doubt anyone would have batted an eyelash.
It's probably about reducing maintenance costs. The public API is implemented by software which calls internal Netflix services/APIs. Over time, those services accrue technical debt and need to be refactored or rewritten. Every system that uses those internal services needs to be updated to match.
A published API makes this more difficult. The behavior of published APIs, particularly those that are in wide use, can not change in any way without raising the ire of developers. This restricts the internal refactoring you can do and makes the whole exercise (already complicated enough) even more challenging.
Working with a small, curated list of apps means that they can coordinate with developers on API changes rather than worrying about maintaining compatibility. This lowers their maintenance costs and increases their architectural agility.
> With something like Twitter, I get it. In order to make money off their customers' use of Twitter's free service, they need to be in control of the customers' experience (so they can do things like show ads)
Twitter didn't need to close the API to make sure ads were shown they just needed to make sure API developers knew there were certain messages they weren't allowed to block. The whole control the experience is a poor excuse for killing an ecosystem that got the company to where it was.
Netflix over-complicates EVERYTHING. And not just because they are big business with a lot of crap to take care of. They do so because they want to have great up-time and slick services across as many devices as possible. Not just one browser and one run-time, like, every android device, every mobile device, every internet-connected game console.
And if you know anything about the way Netflix architects their dev process, you know about the Chaos Monkeys.
So I think, they just decided it was too much work to maintain, on top of everything else, with little feedback. And probably someone was abusing it as well, which equates to more work/maintenance.
Their Dos/Don'ts page shows they were pretty strict about usage of this 'open' api:
So I can totally imagine them thinking this was just too much work to maintain. Its a bit sad, yeah, but, there's not really much value it provided anyone in the first place, there's only so many things you can do with lists of movies owned by Netflix.
I was disappointed to get that email, I have an API key and am using it for an ongoing (small) side project of mine.
It seems counter to everything else Netflix engineering promotes with its tech blog and open source contributions. To be so public and open on one hand, and then shut down the public API on the other seems strange.
Trying to cut down on third-party access to user account functions like managing queues could be understandable, but I hope there is some kind of access to basic Netflix library data. Otherwise people will just turn to custom scraping solutions to get the data anyway.
Same here, have a working side project that has been working like a clock watch for the past 3 years, with a few thousands regular users.
I will now need to see if scraping is a solution that can work.
At the same time, when they announce last year they were stopping the new API keys, I was wondering how long it will take for them to terminate the existing ones.
R.I.P. NetflixItNow - a weekend hackathon Greasemonkey/Chrome extension that sent you an email when user-selected movies became available for streaming (not just disc delivery).
Though the project was short lived, I am very sad that it is no longer possible to implement similar projects.
This just means more people will rely on covertly scraping their data. It also means, much like Twitter and the way they nerfed their developer ecosystem, Netflix will gain much more control over any available 3rd party offerings (as they've clearly outlined). Seems like a very short-sighted trade off if you ask me, but, hey, maybe the public API was just underused and they didn't want to devote more resources to maintaining it.
NFLX would prefer we not measure their offerings against AMZN's. That's what I think, anyway. Amazon has more headliners than they know what to do with - they rotate them on and off Prime's frontpage regularly enough to give the impression you'll never watch all of it. Netflix, on the other hand... Netflix and I fought an 18-month staring contest over whether I was going to watch The Lincoln Lawyer.
I don't think that's the case as they are allowing Can I Stream It? to stay up which is specifically for seeing what streaming services (including Amazon) offer particular titles.
Netflix was my first introduction to webscraping back around 2004 (with Perl and WWW::Mechanize) because they didn't see the need for an API. They've never done anything more than pay lip service to it since they finally caved in and made one. Guess it's back to doing that, or using an alternative like TheMovieDB [1], which has a nice API.
You might be interested in a tool I wrote called goim[1], which is a command + library (written in Go) that loads all of IMDb into either a PostgreSQL or SQLite database. (It takes about 12 minutes for the download and loading of the database from scratch on my personal machine.) It supports complex queries (with fuzzy matching) really easily on the command line. For example, this will find the top 5 ranked Simpsons episodes with "homer" in the title:
And if you're like me and rip episodes off your Simpsons DVDs that are named "S04E12.mkv", then you can rename all of them in one swoop:
goim rename -tv 'the simpsons' *.mkv
It will automatically find the `S04E12` in the file names to get the correspondence between episodes.
Of course, the database has more than Simpsons episodes in it (and renaming works with movies too), but it's my go-to example. :-)
Want to try it out? It's easy. Make sure you have Go installed, then install and load and search:
go get github.com/BurntSushi/goim # ~ 30 seconds (compiles SQLite)
goim load -db goim.sqlite # ~ 1 minute, only movies/tv shows
goim search -db goim.sqlite '%homer%' {show:the simpsons}
Loading/searching is a bit slower with SQLite than with PostgreSQL, but it's more convenient. (e.g., The search command above is over 12x faster with PostgreSQL on my system.)
Sadly, this marks the end of an era for me with Netflix. After an initial 'meh' experience with the DVD rental service when they first debuted, one of the things that really got my attention with them was their developer contest to create a better suggestion service. But it seems that working with the developer community now is a thing of the past for them. Sadly, I foresee more companies going that way.
Wbat is funny is that put up that bounty. It took a years to get a hit and then it got a crazy. What is also funny is before they killed that program, they actually implemented any of the techniques from people that won those contests.
When business schools a few dozen years hence discuss this period of API development, they'll talk of how we learned to use an open API as a weapon wielded by a mid-size company to fend off competitors until the company has grown to a place of market dominance.
I worked for Netflix in 2009 and 2010, first documenting the consumer API and helping out with things like oAuth, and later working on the original iPhone and Android apps, which ran inside a Web view using nothing but HTML, CSS, JavaScript, and the consumer API. (The morbidly curious should see "Mistakes I Made Building Netflix for the iPhone," at http://www.slideshare.net/kentbrew/mistakes-i-made-building-...)
At the time, Netflix didn't run on an API; the API had been retro-fitted onto Netflix. Even a simple thing like "please tell me the availability of all the discs in this season of this television series" took several calls and a fair amount of head scratching to accomplish. Every new device that came along got a slightly different version of the API, support was terribly difficult, and when we launched for PS3, Wii, iPhone, and Android, it became obvious that our own apps had to take precedence.
I am not surprised to see the Netflix consumer API shut down. This will, of course, result in rampant screen scraping and the creation of an unofficial Netflix API, which, when it breaks, will be all Netflix's fault.
What was it, 2003-04 when Blockbuster's engineering team sent Netflix that concession letter? 10 years go by and guess who's stuffing their bra for lack of content.
Does anyone here happen to know how Netflix is charged for content? Specifically, do they pay owners per viewing while they have a title licensed, or do they license get a license for unlimited customer uses? And, even if they do get rights for serving an unlimited number of viewings, do they have to supply the usage data to the content owners, who may use the information in future negotiations.
I ask, because it seems like these details would have pretty significant impact on Netflix's incentives for effective recommender systems and user portals. They would need to balance the satisfaction rates necessary for retention of subscribed customers with variable costs of serving content, especially recently released feature films.
Seems like you could just watch the network for whatever those apps are doing and reverse engineer whatever remains of the API. You might not be able to build a business on that, but you can build your own apps for yourself, friends and your family that way.
If you're an EU citizen, just baksmali the Android App. As long as you don't copy code from their App decompiling is completely legal as per EU law there is no copyright on source code, but only on the implementation.
And for private use the API access will also be allowed.
Though I am not a lawyer, and this topic is still being discussed even in EU courts, so I wouldn't recommend using it for larger projects.
I think the list of 3rd party services they are not going to shut down shows a weakness -- without an easy public API to use, it is less likely other such services that extend and add value to the Netflix experience will evolve.
8 projects made that they are now incorporating into the product proper.
These 8 projects were at cost of management of the public API.
If true that more projects of equal caliber will be developed in the future, what is the opportunity cost of maintaining the API? How would you measure this opportunity cost?
Corollary: If Netflix had gone Tesla with the public API, I'm talking a full developer tool marketplace platform- what would be the opportunity risk/reward conversation look like? I'm thinking would be a very valid strategy for cornering the video media marketplace, setting the groundwork to take a bite out of YouTube/Twitch/etc's marketshare.
Protocols, not companies. There should be a Netflix protocol that any business could host. There should be a Twitter protocol so anyone could set up a Twitter server.
I think it doesn't make sense at all or is at least very dangerous to build a business having a third party as a single point of failure at any point of its core operations.
To generalize even more, a good long-term plan should be free of any kind of single point of failures.
I don't know what is the big deal. It's as if these startups were in a Bachelor/Bachelorette style of competition and everybody but a few lost. It's not like the terms and conditions said the API would be there forever or for everybody.
It is easier to just pull up porn then watch a movie with some nudity and sex it but otherwise your site is great for porn discovery on Netflix, good job.
