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 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.
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.
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.
"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".
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.
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.
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.
false: it's provided them with 8 projects worth incorporating into the project proper.
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.
So help me out here: what is the motivation?
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.
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.
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.
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.
Though the project was short lived, I am very sad that it is no longer possible to implement similar projects.
Netflix API code (very simple): https://github.com/swanson/netflix-it-now/blob/master/check_...
Video demo: https://www.youtube.com/watch?v=h-zXOUsyXjA
Entire repo: https://github.com/swanson/netflix-it-now
goim search '%homer%' {show:simpsons} {sort:rank desc} {limit:5} {votes:100-}
goim rename -tv 'the simpsons' *.mkv
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}
I'm not sure "thank" is the word they wanted.
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.
I used to love Netflix. I was a loving, loyal, evangelical customer and fan.
Now I just find them somewhat useful. In the future, who knows?
It also makes things a bit easier on the technical side after they moved away from generic "REST" to device optimized APIs.
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.
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.
It's Byzantine, and must be renegotiated studio by studio and sometimes film by film.
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.
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 guess Freebase might be a way to go, once you've resolved the initial dataset with wikipedia, update incrimentally with just the changes.
Or, you know, you have to license the material from somewhere.
[1] http://fllix.com
Imagine if they had never had one, would flixter, etc have popped up?
A public API can save you money in the long run by offsetting the risk/reward of trying new things with the data and diversifying.
[1] https://play.google.com/store/apps/details?id=com.sporadicso...
[1]: http://bateflix.com/
To generalize even more, a good long-term plan should be free of any kind of single point of failures.