OpenSocial is best known for its social applications: canvas and profile views powered by JavaScript and Flash. Applications and widgets are just one part of the full OpenSocial offering. Over the past few months the OpenSocial spec has grown to include JSON, Atom, and XML outputs over a RESTful interface. OpenSocial containers MySpace, LinkedIn, and Plaxo already expose social data over these protocols, with additional support from large networks such as 51.com and Yahoo! expected in the near future.
Exposing data over OpenSocial REST foramts is not limited to widget containers. Social web apps such as Flickr, Twitter, or even Facebook could support OpenSocial data standards without ever adding OpenSocial application support to their web pages. Last week I turned TwitterFE into an OpenSocial RESTful container, opening up Twitter data for OpenSocial clients. OpenSocial 0.9, scheduled for release on December 19, will help solidify these new protocols across containers (I found many errata in 0.81 and I am pushing for changes in 0.9). In this blog post I will provide a brief overview of OpenSocial RESTful protocols and its data implementation for any website interested in standardized descriptors of social data.
OpenSocial background
OpenSocial applications request and interpret applications via JavaScript requests. An application might request profile data on the logged-in member viewing the app, write a new story to a member’s social news feed, or store custom data such as a member’s favorite color. These data objects are called Person, Activity, and AppData respectively. Each of these data objects contain a minimal-set of required information and a long list of optional data that varies by implementation. Most social applications store a member ID, username, profile photo, and a profile URL, for example, but specified views on romance or religion are less common.
Yet OpenSocial isn’t just for widget containers. Social web apps can export and import user data via anonymous and/or authenticated requests. You just have to speak the language of OpenSocial data to achieve fluid data interchange between servers. Data requests may occur with or without a login but additional data may be exposed to requesters with proper OAuth credentials for a particular account.
People
People are the center of a social network experience, connecting us to new data and interactions. OpenSocial maps common profile components across containers including e-mail addresses, profile pictures, location, and member bios. Friends lists are a collection of people objects mapped to a particular owner.
The only required person data from a container are a display name and a container-specific identifier such as the numeric auto-increment id you are storing in your users table. Websites need to stick to a specific Person vocabulary to ensure compatibility across sites.
Portable Contacts and OpenSocial RESTful Person objects are wire-compatible formats. The specs are currently aligned but you might hear either one used interchangeably in conversations.
Example
<person xmlns="http://ns.opensocial.org/2008/opensocial">
<id>mysite.com:1234</id>
<displayName>John Smith</displayName>
<name>
<givenName>John</givenName>
<familyName>Smith</familyName>
<formatted>John Smith</formatted>
</name>
<gender>male</gender>
<emails>
<primary>true</primary>
<type>work</type>
<value>john@example.org</value>
</emails>
<ims>
<primary>true</primary>
<type>aim</type>
<value>johnsmith</value>
</ims>
<account>
<domain>mysite.com</domain>
<username>johnsmith</username>
<userid>1234</userid>
</account>
</person>
In the above example I’ve defined some basic data about a fictional user of MySite.com using the OpenSocial Person vocabulary in an XML format. Consuming agents can write a single interpreter for multiple OpenSocial containers and easily display, export, or annotate profile and friend data over this interface.
Activities
Activities are small application updates usually posted to a social news feed. When a member adds an event, posts a status update, uploads a photo, or takes some other action websites usually write a new activity into the member’s feed. These actions are normalized in the OpenSocial context into a specific Activity vocabulary.
Example>
<activity xmlns="http://ns.opensocial.org/2008/opensocial"> <title>Updating my MySite account</title> <url>http://mysite.com/johnsmith/status/123456789</url> <id>mysite.com:1234/activity:123456789</id> <userid>mysite.com:1234</userid> </activity>
The above example normalizes a text-based status update into an OpenSocial activity expressed in XML. I can post this message into an OpenSocial activity stream, open up export capabilities for members, or interface with a wider array of applications (desktop, mobile, etc.) that already support activity stream display.
Advertising OpenSocial support
OpenSocial RESTful resources are described using XRDS-Simple. If you have used OpenID or OAuth you’re likely already familiar with this markup and discovery process. Agents can probe possible supporting containers for application/xrds+xml response support to receive a full descriptor set.
OpenSocial REST containers advertise supported data objects by the object’s name. A type of http://ns.opensocial.org/* advertises RESTful support, data objects available (person, activity, etc.), possible query types, and a hint of specversion (currently “2008”). You might choose to support some or all of the OpenSocial data objects and your XRDS document will serve as the central discovery resource for such data.
Summary
OpenSocial is about more than just widgets and applications rendered in a web browser. The project exposes standardized interfaces and object descriptors for social web components while offering interoperability with very large social networks around the world. Any social website can allow public and private access to member data using OpenSocial RESTful protocols and responses. You will open up new API opportunities, allow import and export of data between sites, and even expose more granular data to crawlers such as Google (if you choose). Interesting stuff that’s just getting started.