Project Description
This is a .NET Wrapper for the Netflix API. Currently it supports low level requests including OAuth signing.

A high level object model is planned.

Full release history here

Release: Preview 5

Jason Lambert added these features:

High Level Guidance on using wrapnetflix

  • The NetflixUrls module contains a bunch of functions that represent all of the API calls you can make. Each function returns a RestCall object with the appropriate parameters.
    • Once you have a RestObject, you can pass it to the NetflixConnection object's RequestXmlResource method. This will add all the right security information and send the request to Netflix.
    • The result can be returned as XML, a string, or as a raw stream. Most of the time the XML version is what you want.
  • I have added a new property called MinDelay. If you set this, it will ensure at least X time passes between each call, thus minimizing the 403 errors thrown by the Netflix API servers.
  • If you're interested in understanding how to make direct API calls, have a look at the code for the SetRating() method in the User class

Source Code organization model

  • The DEV/MAIN/PRODUCTION organizational model is based on recommendations from Microsoft, chosen here because the use of TFS as the store behind Codeplex means this model is probably least likely to cause weird problems with our server interactions
  • DEV contains the latest check-ins from wrapnetflix developers
  • no new code is checked in directly to MAIN branch
  • all new code changes are checked in to the DEV branch, then unit tested (manually using the console application) before they're considered for the MAIN branch
  • once a sufficient amount of new code has been checked in, the DEV branch is copied to MAIN, and a new release is built from MAIN
  • no public releases are built from the DEV branch; only private builds for individual testing are ever produced from the DEV branch

Unit Testing thoughts

I would like to use formal unit tests, but I'm not doing it at this time for three reasons.
  1. Time.
  2. Concern over how often they can run before hitting the daily limits.
  3. Concern over the changing nature of the data we receive.

Once someone is able to overcome #1, I'm sure numbers 2 and 3 won't present any long-term problems.

Last edited Jun 17, 2009 at 5:44 PM by MikeSL, version 13