Live data from Hacker News

Retiring the Netflix Public API

developer.netflix.com

61–70 of 79 posts

Re: Retiring the Netflix Public API

#61
post #46

Earlier quoted context omitted.

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 t…

I think the point is that the resource requested won't exist anymore.

Yeah, I know. That's what 410 means. 404 means that the server couldn't find what you are looking for but says nothing about why.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Not a big deal. I just found it funny that the first change they make is technically wrong.

Re: Retiring the Netflix Public API

#62

This is the problem with modern web companies: 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.

The protocol is hardly the issue with setting up your own movie-search db - it's data.

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.

Re: Retiring the Netflix Public API

#64
post #56

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 Twitte…

The only reason I can think of is licensing. Maybe it's necessary for licensing some of the content they want.

Re: Retiring the Netflix Public API

#65
post #56

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 Twitte…

[deleted]

Re: Retiring the Netflix Public API

#66

This is why I will never create a business based on an API of a third-party. They can take it away at any time..and your business is done.

Even if that company's business is providing the API?

Of course - they can retire said API and don't extend your contract. Or they can force you to a different API etc etc.

Re: Retiring the Netflix Public API

#67

This is why I will never create a business based on an API of a third-party. They can take it away at any time..and your business is done.

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.

Re: Retiring the Netflix Public API

#68
post #56

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 Twitte…

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

Re: Retiring the Netflix Public API

#69
post #34

Earlier quoted context omitted.

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.

If you only need movie information, that there are arguably better sources available now like TheMovieDB.

Unfortunately no, the project in question was specific to Netflix.

Re: Retiring the Netflix Public API

#70
post #56

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 Twitte…

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.

Post reply on HN