Increasingly, web surfers are using the internet to connect with friends, family, and colleagues using social networking sites. Conversations that once took place over email are now taking place in short messages written on someone's Facebook wall or in a brief tweet on Twitter. Connections once made with a handshake are now created using LinkedIn. And when a face-to-face meetings are desired, travel details can be shared using TripIt.
Just as people are using these social networking sites to interact with each other, businesses are also finding ways to inject themselves into the social graph so that they can connect in a more personal way with their customers and also make their web sites an extension of their customers' social experiences.
This week, we are pleased to have released the first milestone of Spring Social, a new extension to Spring that aims to provide a platform upon which social-ready Spring applications may be built. I thought I'd take this opportunity to introduce you to Spring Social and give you a taste of what it offers.
Securely Sharing Social Data
On the surface, developing applications that interact with the various social networks may appear straightforward. Since most of the social networks offer a REST API, Spring's RestTemplate would seem to be all you need. But you'll quickly discover that those social REST APIs are protected by OAuth and that signing a request sent through RestTemplate with OAuth credentials is a non-trivial task.
OAuth is an open protocol that enables a user to share their data hosted on one or more service providers with another application. With access to that data, the application can aggregate, present, and process the information in ways that provide additional value beyond what the service providers themselves ever intended or imagined.
Virtually all of the major service providers support OAuth, including Twitter, Facebook, LinkedIn, TripIt, and Foursquare, as well as the Google and Yahoo APIs. Therefore, OAuth is essential to developing social-ready applications.
At the beginning of an OAuth-secured interaction is a back-and-forth conversation that is commonly known as the "OAuth Dance". In a typical OAuth Dance, there are three parties involved:
- The service provider (such as Twitter or LinkedIn)
- The user who wants to access or update data hosted by that service provider.
- The consumer application that the user wants to share their data with.
The key steps in this dance are as follows:
- The consumer application directs the user to the service provider's site to sign in and authorize the consumer.
- Assuming that the user agrees to grant the consumer access to their data, the flow is sent back to the consumer application.
- The consumer application receives an access token from the service provider.
The access token received in step 3 is the "valet key" that must accompany any request to the service provider's REST API. In OAuth 1, this means that the access token, along with the request URL, parameters, and a few other bits of information are collected together in a base string, encrypted, and sent on the request in an Authorization header. Constructing this header and attaching it to the request is a complicated task. This is the reason that using RestTemplate to access OAuth-secured resources is difficult. If you get it wrong, the service provider will respond with an HTTP 401 for any resource you try to access and debugging the encrypted Authorization header is tricky.
Working with Social Templates
A key component of Spring Social is its collection of social templates. These templates (which leverage RestTemplate under the covers) expose operations of the service providers that they model, handling the intricacies of adding OAuth Authorization headers for you.
Spring Social 1.0.0.M1 includes 4 social templates to choose from:
TwitterTemplateFacebookTemplateLinkedInTemplateTripItTemplate
To use any of these templates, simply create an instance of it, providing the OAuth connection details through constructor arguments. For example, to create an instance of TwitterTemplate:
TwitterTemplate twitter = new TwitterTemplate(apiKey, apiSecret, accessToken, accessTokenSecret);
The four parameters to TwitterTemplate's constructor are all Strings values. The API key and API secret are given to you when you register your application with Twitter (see http://dev.twitter.com/apps/new). The access token and access token secret are granted to your application on a per-user basis at the end of the OAuth Dance with Twitter. At this point, I'm going to assume that you've already obtained all four of these values; we'll circle back to how to manage API keys and tokens a little later.
Creating instances of the other social templates isn't much different. LinkedInTemplate and TripItTemplate each have constructors with the same argument list as the TwitterTemplate constructor shown above. Since Facebook's API security is based on OAuth 2, FacebookTemplate has a slightly simpler constructor that only requires the value of the access token:
FacebookTemplate facebook = new FacebookTemplate(accessToken);
Once you have an instance of one of these social templates, what can you do with it? If you're using TwitterTemplate, perhaps you want to know the authenticated user's Twitter screen name:
String screenName = twitter.getProfileId();
Or for something a bit more involved, maybe you could send a tweet on behalf of the user:
twitter.updateStatus("Hey, I'm tweeting with #Spring Social!");
Similarly, with a FacebookTemplate in hand, you can post to the user's wall:
facebook.updateStatus("Spring Social can also post to Facebook!");
And if you want to examine a user's upcoming travel itineraries, TripItTemplate's getTrips() can oblige:
List trips = tripIt.getTrips();
for(Trip trip : trips) {
System.out.println("I'm traveling to " + trip.getPrimaryLocation() +
" on " + trip.getStartDate());
}
This is just a sampling of the kinds of things you can do with Spring Social's templates. Check out the API documentation to see the other operations that are available.
Managing OAuth Connections
When I created the TwitterTemplate instance above, I glossed over where the API key/secret and the access token came from. Initially, the access token would be received after a user authorizes the application to access their data hosted on the service provider. But you probably don't want to force your users to perform authorization every time they use your application, so you'll need a way to store the access tokens long-term for reuse in future sessions.
In its first milestone release Spring Social doesn't provide an OAuth token management strategy, leaving it up to the application to obtain and manage OAuth details for itself. This is something that we intend to address for 1.0 Milestone 2. In the meantime, however, we can look to Greenhouse for an example of how this might take shape.
In Greenhouse, all of the information about a service provider is stored in a relational database in a ServiceProvider table with the following schema:
As you can see, the ServiceProvider table includes, among other things, the provider's API key and secret. To access an individual service provider record, Greenhouse uses JdbcServiceProviderFactory, an implementation of a ServiceProvider interface:
package com.springsource…
