OpenSocial

CHAPTER 1
INTRODUCTION

The web is more interesting when you can build apps that easily interact with your
friends and colleagues. But with the trend towards more social applications also comes
a growing list of site- specific APIs that developers must learn.

Open Social is a set of common Application Programming Interface (APIs) for web-
based social network applications, developed by Google along with MySpace and a number of
other social networks. It was released November 1 2007. Applications implementing
the OpenSocial APIs will be interoperable with any social network system that supports
them, including features on sites such as Hi5.com, Myspace orkut.com sonico.com,
Friendster and Yahoo . Based on HTML and Javascript as well as the google gadgets
framework, OpenSocial includes four APIs for Social software applications to access
data and core functions on participating social networks Each API addresses a different
aspect: one is the general Javascript API, one for People and Friends (people and
relationship information), one for Activities (publishing and accessing user activity
information), and one for Persistence (simple key-value pair data for server-free stateful
applications).

For launch partners committed to support the OpenSocial APIs included the social
network companies like Bebo Engage.com Friendster hi5 Hyves imeem Netmodular mixi
MySpace Ning Orkut Plaxo,Six apart as well as business-oriented networking companies
LinkedIn,Tianji,Salesforce.com,Viadeo,Oracle and XINGPlaxo and Ning released OpenSocial
support within the first day of its launch.

1
Dept of IT, MLMCE
OpenSocial

CHAPTER 2
OpenSocial API

2.1 JavaScript API

The JavaScript API lives under the OpenSocial namespace and provides access to three
primary ares of functionality:

 People – information about individual people and their relationships to each other
 Activities – ability to post and view updates on what people are doing
 Persistence – a simple key-value data store to allow server-free stateful
applications.

Here are some of the things you can do with JavaScript API:

 Build applications without maintaining your own server

 Build applications that include a server-side component(for offline processing)
 Expose Existing web applications in the context of existing Social Websites
 Add Social features to existing gadgets
 Write one application that can run in the context of many different social websites

The JavaScript API is designed to use standard web technologies.

 It’s packaged as a set of methods in the OpenSocial namespace

 It allows you to use any standard JavaScript programming technique and third-
party libraries
 It includes a full asynchronous callback system to rich support AJAX interactivity

2
Dept of IT, MLMCE
OpenSocial

2.2 RESTful Data API

The RESTful Data API will provide complementary functionality to the JavaScript
API,so you can access people,activities and data from your server.The RESTful data API is also
designed to use the standard web technologies.

 Server interactions are based on the RESTful AtomPub protocol

 Authentication is handled by OAuth

The RESTful API serves as a common protocol understood by all OpenSocial 0.8-
compliant client and servers.It replaces the November 2007 OpenSocial Data API
proposal(based on Google Data APIs).

2.2.1 Overview

This API defines a language and platform neutral protocol for clients to interact with
OpenSocial container servers outside of gadgets on a webpage.As a protocol,it is intended to be
reasonably easy to implement in any language and on any platform.It should also be usable to
across a range of clients,from gadgets operating within a webpage to servers communicating to
synchronize data about a user.The protocol operates primarily in terms of resources and
operations on them.It is defined on the top of the HTTP protocol,and uses the standard HTTP
methods(GET,POST,PUT,DELETE,etc) to retrieve and change server state.

No single data representation is ideal for every client.This protocol defines dual
representations for each resource in two widely supported formats,JSON[RFC4627] and
Atom/AtomPub[RFC4287][RFC5023],using a set of generic mapping rules.The mapping rules
allow a server to write to a single interface rather than implementing the protocol

3
Dept of IT, MLMCE
OpenSocial

twice.OpenSocial containers servers are free to define additional representations but must
support at least the JSON and Atom formats defined in this document.

The protocol deines Activity, Person, Group and AppData resources and collections.Most
operations consist of retrieving(GET), updating(PUT), or destroying(DELETE) these
resources.The protocol provides an optional feature to batch multiple requests together in a
pipeline to avoid multiple HTTP round trips.Finally,it specifies an optional partial update feature
which avoids sending large resources over the wire to update just one field.

4
Dept of IT, MLMCE
OpenSocial

CHAPTER 3

FEATURES OF OpenSocial API

3.1 Many Sites,one API

A common API means you have less to learn to build for multiple websites.OpenSocial is
currently being developed by a board set of members of the web community.The ultimate goal is
for any social website to be able to implement the API and host 3rd party social apps.There are
many websites implementing OpenSocial including Engage.com, Friendster, hi5, LinkedIn, Ning
Oracle, Viadeo, XING,Orkut.

Fig 3.1

5
Dept of IT, MLMCE
OpenSocial

3.2 Server Optional

OpenSocial is built upon gadgets,so you can build a great,viral social app with little to no
serving costs.With the Google Gadget Editor and a simple key/value API,you can build a
complete social app with no server at all.Of course,you can also host your application on your
own servers if you prefer.In all cases,Google’s gadget caching technology can ease your
bandwidth demands should your app suddenly become a worldwide success.

3.3 Learn Once,Reach Across the Web

One of the most important benefits of OpenSocial is the vast distribution network that
developers will have for their applications. The sites that have already committed to supporting
OpenSocial -- Bebo, Engage.com, Friendster, hi5, Hyves, imeem, LinkedIn, mixi, MySpace,
Ning, Oracle, orkut, Plaxo, Salesforce.com, Six Apart, Tianji, Viadeo, and XING -- represent an
audience of about 200 million users globally. Critical for time- and resource-strapped developers
is being able to "learn once, write anywhere" -- learn the OpenSocial APIs once and then build
applications that work with any OpenSocial-enabled websites.

6
Dept of IT, MLMCE
OpenSocial

CHAPTER 4

KEY CONCEPTS

Social applications revolve around people and their relationships. OpenSocial provides a
standard way for websites to expose their social graph and more. Seeing the activities of other
people helps you stay up to date with your friends, and allows everything from resumes to videos
to spread virally through the graph. OpenSocial also provides a way for application data to
persist on a social networking site, as well as specifying the different ways that an application can
be viewed within an OpenSocial container. Finally, OpenSocial defines an API through
which users of web services, mobile devices, and desktop applications may interact with social
data.

4.1 People
It's people! Social graphs are made out of people! People are a fundamental part of social
networking software and the OpenSocial API. The Person object provides access to a user's
information. Part of this information is stored in the user's profile and, depending on the site, can
include anything from "favorite TV shows" to "5 things you'll find in my bedroom." The other
important user information is the set of connections they have in the social graph and this is
covered in the Relationships section

There are two Person objects that can be requested directly—the VIEWER and
the OWNER. To understand the distinction, imagine you're checking out a coworker's profile on
Orkut. In this case, you are the VIEWER and your coworker is the OWNER. It's also common to
view your own profile, in which case you are both the VIEWER and the OWNER, and some
applications may choose to handle this case differently. OpenSocial also provides for the case of

anonymous viewing, where the gadget will not be able to access the VIEWER's information.

7
Dept of IT, MLMCE
OpenSocial

4.2 Relationships
The ability to create relationships is what turns a multi- user application into
social software. Being able to share information and interact with friends changes the dynamic of
user experience—you're engaging with people, not software.

There are two representations of sets of people available to OpenSocial—

VIEWER_FRIENDS and OWNER_FRIENDS. In the case where you're checking out
a coworker's profile, requesting VIEWER_FRIENDS will return the set of users that are friends
with you, while requesting OWNER_FRIENDS will return the set of users that are friends with
your coworker. Logically, if you're viewing your own profile, VIEWER_FRIENDS
and OWNER_FRIENDS will be the same set of users. Also, if the container supports
anonymous profile browsing, then the application won't be able to access the set of
VIEWER_FRIENDS.

Note that OpenSocial makes no assumptions about the relationship between VIEWER and
OWNER. The VIEWER and OWNER could be friends, but if you're looking at a stranger's
profile, there's no relationship between you, the VIEWER, and them, the OWNER.When an
application wants to interact with or display data for "friends of friends", the
OpenSocial specification supports extending a query for VIEWER_FRIENDS or
OWNER_FRIENDS by a NETWORK_DISTANCE parameter. Containers can optionally
support "friends of friends" queries, "friends of friends of friends" queries, and so on.

4.3 Activities
Since we can't be online all the time, it helps to have a record of what our friends have
been up to, so long as your friends want to share that record. Seeing how other people are
interacting with a social application also allows you to learn new features and uses of the
application, so activity streams are one of the major drivers for organic growth of applications.

OpenSocial exposes activity streams, which are a collection of actions a user has taken in
the context of a given container. These activities can include interaction with the container itself,

8
Dept of IT, MLMCE
OpenSocial

such as updating your profile or installing a new gadget, or interaction with an OpenSocial
application, such as sending your friend a virtual gift or setting a new high score in a game

Activity templates allow application developers to define messages with placeholders for
pieces of application or user data. This separation of data and presentation allows multiple
activities to be combined into activity summaries—consolidated bundles of activities that let
users know what their friends are up to without having to wade through a flood of messages.

4.4 Persistence

Applications can provide a richer user experience if they can save their state between
sessions . OpenSocial defines a data store that applications can use to read and write user-specific
data. This data store can be read by anyone who can see the gadget, but only the VIEWER's user-
scoped data is writable.

Clearly this free data store could be abused, so containers may implement quotas or rate
limits to preserve their disk space. However, OpenSocial does not currently define these policies.

Since application data is often created based on user inputs, OpenSocial

containers perform automatic HTML escaping of all application data. However, developers have
the option of turning off this escaping by setting the escape Type parameter on
newFetchPersonAppData and getField calls. See the Persistence section of the OpenSocial
Developer's Guide for more details.

4.5 Views

Containers can support several different locations where gadgets may be rendered. Such
locations are formally called views (formerly Surfaces in earlier versions of the API). All
gadgets (not just OpenSocial applications) have become view-aware. A gadget can ask which
view it is currently being rendered on, as well as what views the container supports.

9
Dept of IT, MLMCE
OpenSocial

Containers define their own views, but the specification defines the following standard
views in the gadgets.views.ViewType object:
 Profile - A gadget on the profile view is rendered alongside other applications
in the user's profile, so it will be smaller and can't support passing URL
parameters from the container to the gadget.
 Canvas - A gadget in the canvas view is rendered by itself, so it will have lots
Of real estate and URL parameters passed to the container page can be
forwarded to the gadget.
 Home - A gadget in the home view is rendered on a private "homepage" where
the OWNER is always the same person as the VIEWER. There may be multiple gadgets
present in this view.
 Preview - A gadget in the preview view does not have access to either the OWNER
or VIEWER objects. This view is intended to provide "test drive"
functionality so that gadgets can demonstrate functionality for potential users.

In addition to requesting data about the current view, gadgets may also request that the
container navigate the user to another view. Imagine a news gadget that normally runs in a small
profile view that changes to a full canvas view if the user clicks on a headline to get more
information. Gadgets can choose the best rendering context for their current state

When navigating to another view, a gadget may also request a change in OWNER.
For example, imagine an application that places a survey on the user's profile view. This
application may want to provide links to the user's friends' profiles, so that the user can see which
surveys his or her friends are currently displaying.

Containers can also specify a template that applications can use to generate
URLs to a specific application canvas and user. Such URLs can be shared via activity updates
and printed on external websites, so linking to applications from external sources is easy.

10
Dept of IT, MLMCE
OpenSocial

CHAPTER 5

API PATTERNS

This section describes several common patterns in the OpenSocial API.

5.1 Making Requests

The OpenSocial API queries the container asynchronously for most of its calls, which is
why most OpenSocial methods don't directly return data, but rather allow you to specify a
callback that will be executed when the server's response is ready. Of course, making lots of
asynchronous requests isn't always ideal, so the API allows for batch requests to
allow developers to ask for many pieces of information at once. A developer can
create an opensocial.DataRequest and add several individual request objects to it. Upon
receiving the DataRequest , the container can process each request optimally and return the
results of each operation as a batched result object. Containers must preserve the
semantics of executing requests in serial order, though. A request that contains a write and then
a read must return the newly written data, while a request that contains a read and then a write
must return the data that was present before the write took place.

5.2 Capabilities Discovery

The gadgets and OpenSocial specifications determine the common APIs that
all containers will support, but there are cases where a certain method or a profile field will be
offered as an extension in some containers. To help developers write gadgets that can take
advantage of these extensions, yet degrade gracefully in their absence, these APIs
include gadgets.util.hasFeature and opensocial.Environment.supportsField methods to query the
container at runtime and determine which features are available.

11
Dept of IT, MLMCE
OpenSocial

5.3 Actions Requests and Permissions

There are cases where a gadget may wish to perform an action that needs approval by the
user or mediation by the container. OpenSocial supports "request" features that allow
the container to decide how to handle the interaction with the user. Functions like
opensocial.requestCreateActivity and opensocial.requestPermission allow the container to inject
its own policy decisions into the gadget execution flow and notify the gadget of the result. Under
this specification, it is equally valid for a container to defer to the user, always approve,
always deny, or use any other method to determine responses to request calls. Additionally, this
allows the container to enforce UI flows in a safe and integrated way.

5.4 Fetching content from remote servers

Gadgets can use the gadgets.io.makeRequest method to pull HTML, JSON, and ATOM
data from remote servers.

The gadgets.io.makeRequest call can also be used to pass data from gadgets
back to application servers in a way that cannot be spoofed. The container is expected
to mediate communications from the gadget to the application server (e.g. ilike.com).
Therefore trusted content fetching has two main steps: [1] the gadget contacts the container, and
[2] the container contacts the application server.

1. When the gadget contacts the container, the container needs to be able to validate
any parameters it knows about: the viewer id, the owner id (if known), and
the application id. Validating these parameters is an implementation detail that
may vary between containers. For example, Orkut uses an encrypted token passed in
the document fragment of the gadget URL.
2. When the container contacts the app server, the app server needs to be able to validate that

12
Dept of IT, MLMCE
OpenSocial

the parameters really came from the container (and were not forged by some other
entity). OpenSocial uses OAuth's parameter signing algorithm Note that most of
the functionality in the OAuth spec, including token exchange, is not required;
OpenSocial only plans to use the parameter signing piece of the spec (including
timestamp and nonce). OpenSocial permits the HMAC-SHA1 method (except
that the key is a shared secret between container and app, not a
concatenation of tokens as specified in section 9.2 of the OAuth spec) and the
RSA-SHA1 method. HMAC-SHA1 is faster and easier to implement, but it requires
more coordination than RSA-SHA1.

If a user needs to fetch data from a protected resource, the makeRequest call supports for
OAuth authentication via a container proxy. Gadgets can now access protected web services
without requiring the user to share their password with the gadget, allowing for sophisticated and
secure integration with web APIs that support OAuth.

5.5 Caching
When gadgets call makeRequest, the calls may be cached. This is great for reducing the
load that your servers have to be able to handle, since OpenSocial applications may
have millions of users, each requesting data from your server. However, this caching of
makeRequest calls can wind up displaying old data to users if the content returned by your
server changes often.

If you expect the content at the URL you are fetching to change frequently, you may
want to work around the automatic caching with a more finely grained method. You can define a
refresh Interval parameter, which should be specified as the number of seconds that should elapse
before the makeRequest call requests content from your servers again. For example,
specifying 10 will mean that the container would only query the supplied URL once every
10seconds, , no matter how many people are using the application. Specifying 0 will query the
server each time the function is called, effectively bypassing the cached version.

13
Dept of IT, MLMCE
OpenSocial

CHAPTER 6
COMPILANCE

So what does it mean to be an OpenSocial container?In a practical sense,it means that a

site can run any application built on the OpenSocial APIs.This implies a number of things:

1. The container must implement all methods in the JavaScript API

Reference.

Methods may return the error code -

opensocial.ResponseItem.NOT_IMPLEMENTED for a specific method if the
container does not support a specific request. No additional public methods or classes may be
put on the OpenSocial namespace at any level. The required methods and fields are defined in
the following JavaScript files:

 activity.js
 address.js
 bodyType.js
 collection.js
 datarequest.js
 dataresponse.js
 email.js
 enum.js
 opensocial.js
 organization.js
 person.js
 phone.js

14
Dept of IT, MLMCE
OpenSocial

 responseitem.js
 url.js

2. The container must only use the specified extensibility mechanisms for any
container-specific extensions.

Extra person, activity or other object fields should be defined in an enum under the
container's namespace, and the environment should allow applications to discover these fields.
For example, if the field orkut.PersonField.SPECIAL_FIELD is defined as
"orkut.specialPersonField",then
opensocial.getEnvironment().supportsField("person","orkut.specialPersonField") and
opensocial.getEnvironment().supportsField(opensocial.Environment.ObjectType.PERSON,
orkut.PersonField.SPECIAL_FIELD) should both return true.

Any extra data request types should be available with a namespaced call like
myspace.newFetchAlbumRequest.The gadget would then use
batchRequest.add(myspace.newFetchAlbumRequest(...)). Any extra objects may be added to
the container's own namespace. These objects can be returned from person.getField or
other similar requests.

3. The container must satisfy the Gadgets API Specification

In short, this requires handling three types of requests: the Gadget Rendering
Request, the Gadget Metadata Request, and the JavaScript Request.

15
Dept of IT, MLMCE
OpenSocial

4. The container must support the RESTful API Specification.

Containers must provide both JSON and AtomPub represenatations of data.

OpenSocial uses HTTP GET to retrieve, PUT to update in place, POST to create new,and
DELETE to remove. POST operates on collections and creates new activities, persons,
or app data within those collections.

16
Dept of IT, MLMCE
OpenSocial

CHAPTER 7
HOW IT WORKS?
The figure below shows how a gadget works in a social website. Firstly it takes the
information needed for it’s working from the container website. The information needed includes
information about his or her profile data and friend’s data.The gadget includes some simple html,
and javascripts.Also a gadget can include some falsh objects which is optional.The gadget send a
invoking function to container asking the particular data.It return a callback function which is
used by the gadget for retrieve the data when the server’s response is ready,By using the built in
functions the gadget can perform the required function.

Fig 7.1

17
Dept of IT, MLMCE
OpenSocial

CHAPTER 8

WRITING A SIMPLE APPLICATION

8.1 Writing a “Hello,World” gadget

The simplest gadget is just a few lines of code.This gadget displays the message
“Hello,World!” :

<?xml version=”1.0” encoding=”UTF-8” ?>

<Module>
<ModulePrefs title =”hello world example” />
<required feature =”opensocial=0.8”>
</ModulePrefs>
<content type=”html”>
<![CDATA[Hello,World!]]>
</Content>
</Module>

Note the following about the “HelloWorld!” example :

 Gadgets are specified in XML. The first line is the standard way to start an XML file.
This must be the first line in the file.
 The <Module> tag indicates that this XML file contains a gadget.
 The <ModulePrefs> tag contains information about the gadget such as its title,
description, author, and other optional features.
 The line <Content type="html"> indicates that the gadget's content type is HTML
 <![CDATA[ ... insert HTML here... ]]> is used to enclose HTML when a gadget's content
type is html.It tells the gadget parser that the text within the CDATA section should not be
treated as XML.The CDATA section typically contains HTML and JavaScript.

18
Dept of IT, MLMCE
OpenSocial

 </Content> signifies the end of the Content section.

8.2 Accessing People and Profiles

This is a simple example that lists the names of your friends. But first, it's important
to understand the roles defined by the OpenSocial API:
 Viewer: the user logged into the browser. As a viewer you might be viewing your
own page, or you might be viewing another user's profile.
 Owner: the user who owns the profile or application in question.
 Friends: users whom the owner or viewer has added as friends in the
container.

The "List Friends" example discussed in this section fetches the viewer and the viewer's
friends and displays a list of the viewers friends. It illustrates how to fetch and operate on data in
an OpenSocial application. The basic steps are as follows:

1. Retrieve the data.

 Create a DataRequest by calling opensocial.newDataRequest().
 Call DataRequest.add(request) once for each type of data you would like to
retrieve
 After you add all the individual requests to your DataRequest object,call
DataRequest.send(callback).
2. Implement a callback function to process the retrieved data.
 Once the server request has been processed, the callback function is excecuted.This
function takes one DataResponse parameter that has the results of the request.In
“List Friends”, the DataResponse contains the viewer and the viewer’s friends.The
callback function processes the data in the DataResponse.

19
Dept of IT, MLMCE
OpenSocial

CHAPTER 9

SOCIAL DESIGN BEST PRACTICES

If you're new to developing social applications, it can be difficult to immediately grasp

how good applications facilitate fun and meaningful social experiences. To accelerate your
learning, we've come up with a list of a few light-hearted recommendations around building
good social applications. Not all of these "best practices" are necessary in every case, but they
might spark thoughts about finding new users, keeping old ones, and leveraging the social graph
for fresh content and viral spread.

9.1 Engage Quickly

Across containers, there's a common tendency for a user to take a chance on an
unknown application, and shortly thereafter remove it if no immediate value is found. The lesson
to be learned from this interaction is that first impressions really do matter, and it's necessary
to engage the user quickly before attention is lost. To this end, we suggest you focus on the 30-
second experience; before distracting the user with expert features or sending invites, slow
down and give the user a simpler taste of what your application is about.

9.2 Mimic Look and Feel

Across OpenSocial containers there can be a lot of variation in the look and feel of pages
and profiles. When designing your application, it can help to attempt consistency with the
container UI by using similar fonts, tabs and buttons. In cases where applications strive for
stronger identity, it can be good to create a UI look and feel which is slightly distinct but still
aesthetically strong to play on a user's tastes and need for self expression.

20
Dept of IT, MLMCE
OpenSocial

9.3 Enable Self Expression

The profile page in a container is often a representation of a user's identity, interests and
tastes. From the perspective of the owner, it's a means for self expression and a starting point for
exploring the social graph. From the perspective of viewers, it's a place to learn, communicate,and
find shared interests. Applications best take advantage of the profile by enabling self
expression through common interests around entertainment, brands and groups. Self expression is
also enabled through specific forms of communication like gestures and gifts or conversations

around special topics.

9.4 Make it Dynamic

Good social applications aren't only static badges of self expression; they dynamically
change to provide an interesting experience across sessions. Change can be derived from the
social graph as friends interact with the application to change its state. Change can also occur as
the application internally generates new content. In both cases, the day-to-day changes can help to
keep an application interesting and desired over time.

9.5 Expose Friend Activity

A particularly easy way to make an application dynamic and social is to record and
present the activities of friends who are using the application. This could be thought of as an
application-specific activity stream in which the news and updates of friends are
always presented in the context of the application itself. From these activities, users become
more aware of how others are using the application, driving increased use and change.

9.6 Browse the Graph

Exposing the activities of friends is one method among many for passively browsing the
social graph. Users are often interested in low-effort interactions like viewing a friend's most
recent activity, comparing content and choices, and indirectly interacting through their own
activity. In supporting this style of interactions, it's essential to make it easy to browse what

21
Dept of IT, MLMCE
OpenSocial

friends are doing. This is often achieved by linking names to a user's container profile or even
creating application-specific user profiles which provide an overview of a user's activity and
content.

9.7 Drive Communication

Browsing friends' activities and content often flows well into conversation,
creating an opportunity to develop deeper social interaction. In places where communication
can happen, it's good practice to make the option explicitly available. This can be done in a more
persistent, public manner through a comment system or sharing wall. It can also be done in
private by linking into a container's messaging, email or instant messaging systems, or even
through an internal communication layer like pokes or other simple gestures and messages.

9.8 Build Communities

A container's entire social graph is often huge, and even a user's immediate social
circle might be too large for a user to easily track. By growing smaller communities and making
them accessible, an application can provide rich and interesting functionality that enhances the
overall social experience. There are three categories of communities which applications
commonly build and utilize:
 Grouped relationships (e.g. best friends, family, classmates, etc.).

22
Dept of IT, MLMCE
OpenSocial

REFERENCES

1. http://code.google.com/apis/opensocial

2. http://en.wikipedia.org/wiki/OpenSocial

3. http://www.opensocial.net

4. http://www.opensocial.org

23
Dept of IT, MLMCE