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.
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 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.
<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>email@example.com</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 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.
<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.
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.