Netflix API Developer Blog

I tend to go by "JR" a good deal. There's lots of reasons for that, but suffice to say that amongst my friends, family and co-workers, if you asked about "JR" they would know who you were talking about. Widening that circle out a bit more, however, things start getting a tad fuzzy. Folks might wonder if you meant a character from an 80's nighttime soap, or the Japanese Railroad, or an Electronics Retailer who folks continually forget also contains an ampersand. Turns out, while it's mighty handy short-hand, using the two major letters of my hyphenated first name isn't terribly good at uniquely identifying me.

For that, you'd need to toss in a lot of extra information that may be redundant with my neighbor, or the guy who stood behind me at the Social Security desk years ago. It's also the reason that there's a sizable chunk of information one needs to provide for absoulte identification, because, unfortunately, we're analog creatures who just don't map that well to digital references.

The same can be said for a lot of the titles in our catalog. If I say "Batman", what am I referring to? Do I mean the latest movie featuring that character which doesn't have his name in the title? The 1989 movie? The Animated series (by either Paul Dini or the newer one)? The Classic 1966 TV series? Or do I mean the 1940's Serial? Truth is, "Batman" just isn't good enough. What's more, these things tend to change around a good deal. A one off TV special may strike an unexpected chord with an audience, return as a Series, that eventually winds up being a movie.

When it came time for us to try and figure out what to use as an identifier for a given title in our catalog, there was a lot of arguing. Eventually, what won out was the most REST-ful approach we had, which was to make a movie's ID are resolvable URL. The nice thing about this approach was that you, dear programmer, didn't have to suss out and build some complicated URL in order to get things, but instead could walk our catalog pretty easily. Unfortunately, the problem is that we may have done too good a job at making it easy.

Folks wanted to find patterns. They thought that since 90% of the ID looked the same between 10 randomly picked movies, they could toss out the "extra" bits. Unfortuantely, it really doesn't work like that. It's a bit like saying "Well, everyone with the first name "Bob" in zip code 60609 has the last name of "Smith" so I don't need to store that." That approach works great right up until Bob Johnson moves in.

I'll even note that while the ID currently resolves to a nice URL, it may not always do so. The ID will still work as a movie ID however.

All this is a long winded way of saying Treat the ID as an opaque value, don't try taking it apart and "find the value". It may work for a bit, but you're just going to drive yourself nuts when it doesn't later. The movie ID is the full on value in the ID field. So when I refer to movie "http://api.netflix.com/catalog/titles/movies/70039237" we'll both know exactly what I'm talking about.