A catalog containing only a list of watch instantly titles would be extremely useful. Something like http://api.netflix.com/catalog/titles/watchinstantly
Message edited by whurlston 2 years ago
6 years ago
Richly parametrized search is being strongly considered for our next major release. In the short term your best option is to pull the complete catalog index at catalog/titles/index and filter the list by format.
6 years ago
Thanks for the reply. The search would be even better than my suggestion.
6 years ago
maybe i'm missing something obvious, but is there a faster way to get the format than to query
ility" rel="http://schemas.netflix.com/catalog/titles/format_availability" title
for every video that gets returned? from what i can tell, if i want to filter a list of 10 videos to the ones that are just IW available, i need to make N http requests, is that correct?
6 years ago
Instead of going this route, you could go to http://api.netflix.com/catalog/titles/index and get the catalog index, which would return you all the catalog titles (the entrie catalog). Once you get that, you could look for the <title_index_item> containing the category with term = "instant" and not "DVD". This would return you a list of instant (only) titles.
seems like all titles would be a pretty big list - looking at the docs that isn't a query you can page on, is my assumption correct?
Yes, that is right. It contains the entire catalog (all the titles) and the pagination params are not supported for the index.
It might be easier for you to use Title Expansion to get at the formats in titles in search results and other queries. Check out that topic in the REST API Conventions.
I'm working on a C# deserialiser class for the catalog with an option return a catalog of only the watch instantly titles.
5 years ago
Has any progress on this? It seems pretty silly to retrieve the entire catalog when only looking for watch instantly titles.
5 years ago
the netflix servers must be being absolutely hammered by the queries for the total catalog and for the additional information. the customer i'm working for has absolutely no interest in DVD purchasing or renting: they are solely and exclusively interested in providing their users with the ability to watch content online.
i'd say that it would be quite important to not have the netflix servers waste an enormous amount of their time just being used to work out what is _not_ going to be even looked at.
5 years ago
Thank you for your concern and interest in this topic. We use a method known as "caching" which allows us to generate the page content once, then store it for the 24 hour period for which it's valid. With the addition of handling compressed or "gzip'd" requests from most clients, the resulting requires virtually no CPU processing to generate, a tiny amount of disk space to store, and about the same amount of bandwidth to transmit as a couple of our large box art images.
In fact, it would require far more work on our end to create a customized list of movies for each request, thus the reason we make the catalog list available. The beauty of that solution is that you can store that file locally into a database and reduce the number of calls you have to make against our servers and thus not eat into your total number of requests per day.
As for making the streaming content available, there are a number of restrictions we have to respect in order to provide streaming content at all. We are making the streaming content available for some partners who we can ensure will respect those restrictions. We'd love to be able to offer it to more folks, but currently, it's just not allowable. It is something we're working on, but please be patient, as these sorts of things can take quite some time and involve issues that are not technical in nature.
Thank you again for your concern.
JR, thanks for getting back to me. i will pass this on to my client because their business depends - pretty heavily - on being able to provide instant-watch capabilities.
btw - i understand the issues behind streaming content: i understand that they stem from the permission to distribute, and the formats in which they can be distributed, lying with the _director_ of the film - you can't even compress or encrypt the stream, without the director's permission on a per-film basis, because that is not "transmission in original form"!
the cacheing idea is pretty fascinating to hear how you came up with that solution.
here's the issue: the intent of the client i'm working for is to not have any server infrastructure, because _their_ customers do not want to have to pay for it, maintain it, especially when they are looking to order millions of units. (personally, i think it's technically unrealistic to expect there not to be any server infrastructure, but hey, that's what they don't want to have to pay for).
so that means that each unit would have to make copies of the catalog, actually on the unit. thus, you would potentially have several million units suddenly dropped onto your network, all of them performing the exact same queries - all presumably using the exact same API key (and presumably with a copy of the secret key on the millions of units, as well).
clearly, that can't happen, which means a rethink on the way that the authentication and identification side of the netflix API operates.
unless we can come up with something that e.g. just uses the units for "watching", and we use the standard netflix web site for queueing and searching, but even then, there's still cooperation required between the units, the netflix servers and some magic box [which the customers do not want to pay for].
It does sound like a thorny issue to solve, however even in a world of Web 2.0 architecture, there needs to be some level of compromise. I will first state that your initial design is flawed simply because your access key is limited to only 5,000 requests per day, and is also limited to only so may requests per second. That means that without some sort of centralized distribution mechanism, you're limited to only being able to service 5,000 machines. We do make certain allowances for some large partners, however we usually deal with them directly. If you're interested in pursuing that sort of relationship, you can have them contact alliances at our company domain dot com.
There are a number of ways that this can and is resolved from a device standpoint (e.g. the interfaces provided for XBox, LG Bluray players, and others.), and naturally, we'd want to know more about the devices so that we can help craft a solution that's best for customers as well as the service providers.
I should also note that as a developer in that sort of situation, you would need to take steps to ensure that your API Key and secret are as securely stored as the Customers Auth token and secret, lest those keys fall into inappropriate hands and you are unable to service even those 5,000 requests. I'll note that these same sorts of restrictions are in place for even large end services like Amazon, Google and Yahoo so you may want to consider an alternate strategy that could handle content from them as well.
5 years ago
We do, however, also give another 5K requests/day per auth'd sub, so if the app is sub-focused, it can scale to higher usage levels. We can also config apps that are sub-focused so that their keys only work with sub-auth'd calls, which can minimize the value of your secret to an attacker.
Who can I talk to in order to get rights to stream content to my software?
As Michael pointed out in a different thread,
"Try sending an email to alliances at our domain name dot com. We get tons of partnership requests around instant watching and the engagement cost per partner is quite high, even during the biz dev phase so make a really strong case with your first email. You're competing for cycles with partners like Samsung, LG, XBOX, etc."
New posts are not allowed
© 1997-2013 Netflix, Inc. All rights reserved.