Netflix API Developer Blog

Earlier this week we rolled out some incremental API improvements and bug fixes.  Here are the highlights:

users/current resource

This resource returns a link to the currently authenticated user.  You can now access the active user's associated API resource without extracting the user ID from the OAuth access token response.  This should make use of OAuth libraries that don't support standard response extension easier to use. 

On a related note, we also are in the process of removing the need to pass the application name into the authorization (login) URL, which will remove the last of our (standard-compliant, but difficult) OAuth extensions that tend to trip up some OAuth libraries.

gzip support

gzip compression of API responses is now enabled for clients that pass the gzip accept header (see Conventions documentation for more details).  We typically see at least a 2x latency improvment in calls that use gzip- even more on larger responses and for clients on slower network connections.

lost request tokens

We addressed a couple bugs that lead to request tokens not getting passed in authorization service callbacks.

category scheme URL fix for catalog index

The category scheme URL for title formats in the index was incorrect and inconsistent with similar references in other resources.  We added the correct category reference to the catalog index.  The older, incorrect reference will be maintained until the next versioned update of the API, at which point the old, erroneous reference will be removed.

API URL 404s

We found a few cases where the API was returning responses for badly formatted URLs.  The API should always return a 404 if the URL supplied is not an exact match for the resource URL.  We don't want to be flexible in accepting near-miss URLs since they are also resource IDs, which there should be only one of for each resource.

The only flexibility we continued to allow short-term is the use of trailing slashes on resource names.  We will eventually disallow those as well, but we chose not to return 404s for resource URLs with this error until we do the first API release with a version change, in order to give developers time to migrate any old code that contains this URL error to the new API.

This is a good opportunity to remind everyone that you should be using API versioning to protect your code from any interface changes introduced in new versions of the API (see Conventions reference mentioned above for more information).  We avoid making interface changes whenever possible, but sometimes they are unavoidable.  API versioning is your friend.  Also note that we reserve the right too extend the interface at any time, e.g. new XML elements, API resources or URL params) without versioning the API.


I hope everyone enjoys these improvements.  Happy coding!