Last week, I introduced you to Spring Social's Service Provider "Connect" Framework and showed you how it simplifies creating connections between a user's local application account and their accounts on Software-as-a-Service (SaaS) providers. Today I want to show you how to extend the service provider framework to handle connections to providers that aren't directly supported by Spring Social.
Extending Spring Social for Netflix
Suppose that you're developing a movie review website where users can go to read and post short movie reviews. Normally, the movie reviews are displayed with the most recent entries appearing first on the home page. But if a user has connected their account to their Netflix account, then you can show them reviews for the movies in their Netflix disc queue. To pull this off, you'd like to take advantage of Spring Social's Service Provider Framework for connecting your user's accounts with their Netflix accounts. Spring Social 1.0.0.M2 doesn't include a Netflix service provider or API binding, but can be easily extended to work with providers that aren't directly supported.
In this article, I'll show you how to build on Spring Social's Service Provider Framework to enable connectivity with Netflix. We'll start by developing a Netflix service provider implementation, then build a simple API binding to support our application's needs. The techniques used to develop the Netflix service provider can be applied to extend Spring Social to support almost any service provider. You can follow along by reviewing the sample code on GitHub.
Getting to Know Netflix' Authorization API
Before we can start developing the Netflix service provider implementation, we need to do a bit of up-front research to get to know a few basic details about how the Netflix Authorization API works.
The first thing we need to determine is what authorization protocol Netflix uses. The Authentication Overview section of the Netflix API documentation tells us that they use OAuth, but doesn't explicitly tell us which version of the OAuth specification is in play. Therefore a bit of detective work will be required.
Down the page a bit (under the "Those Pesky OAuth Parameters" header) we see mention of consumer keys, nonces, and timestamps. These are things that are not applicable to OAuth 2, so Netflix must be an OAuth 1 provider. Furthermore, the description of the oauth_version parameter being set to "1.0" serves to confirm that Netflix implements OAuth 1.
Now we know that Netflix uses OAuth 1. But it's also important to know whether they implement version 1.0 of the specification or version 1.0a. Service providers usually don't spell this out in their documentation and the oauth_version value should be "1.0" in either case. There are a few tell-tale signs, however, that point at a particular version of the OAuth specification. Here are a few clues that indicate that OAuth 1.0 is in play:
- The
oauth_callback parameter is sent on the authorization URL and not the request token request.
- There is no notion of verifiers and no
oauth_verifier parameter must be sent to the access token URL.
For OAuth 1.0a, watch for these signs:
- The
oauth_callback parameter is sent in the request token request and not in the authorization URL.
- A verifier is received from the provider in the callback and an
oauth_verifier parameter must be sent to the access token URL.
Looking for these clues in the Netflix documentation, we determine that Netflix uses OAuth 1.0 (not 1.0a). This information is significant and will be useful as we define our service provider implementation.
Finally, we need to know what the request token, authorization, and access token URLs are. Further down the page (under the "Making Protected Calls" header) you'll find details that tell us that the needed URLs are as follows:
- Request Token URL: http://api.netflix.com/oauth/request_token
- Authorization URL: https://api-user.netflix.com/oauth/login
- Access Token URL: http://api.netflix.com/oauth/access_token
Pay particular attention to the protocols used in the request and access token URLs. Most providers are flexible in this regard, recommending that you use https. In my experience with Netflix, however, I've found that if you ask for a request or access token over https, Netflix will complain that the request signature is invalid. The authorization URL works fine over https, though.
Developing a Netflix Service Provider Implementation
To create a new service provider implementation, we'll need to extend either AbstractOAuth1ServiceProvider or AbstractOAuth2ServiceProvider. These two classes provide OAuth version-specific base functionality for OAuth 1.0/1.0a and OAuth 2, respectively. Since Netflix is an OAuth 1.0 provider, our NetFlixServiceProvider will need to extend AbstractOAuth1ServiceProvider:
package org.springframework.social.movies.netflix;
import org.springframework.social.connect.oauth1.AbstractOAuth1ServiceProvider;
import org.springframework.social.connect.support.ConnectionRepository;
import org.springframework.social.oauth1.OAuth1Template;
public final class NetFlixServiceProvider extends AbstractOAuth1ServiceProvider<NetFlixApi> {
public NetFlixServiceProvider(String consumerKey, String consumerSecret, ConnectionRepository connectionRepository) {
super("netflix", connectionRepository, consumerKey, consumerSecret,
new OAuth…
