An Orkut Application via a JSON API

I talked about delegating rendering in Symfony for creating a JSON API. Now here’s a consumer: an Orkut opensocial gadget:

MobshareOrkutAPI = {

	api_url: 'http://api.mobshare/api.php',
	cache_time: 0, //0 to disable

	makeCachedRequest: function(url, callback, params, refreshInterval) {
	  var ts = new Date().getTime();
	  var sep = "?";
	  if (refreshInterval && refreshInterval > 0) {
	    ts = Math.floor(ts / (refreshInterval * 1000));
	  if (url.indexOf("?") > -1) {
	    sep = "&";
	  url = [ url, sep, "nocache=", ts ].join("");, callback, params);

	call: function(module, action, params, callback) {
		var options = {};
		options[] =;
		this.makeCachedRequest(this.api_url + '/' + module + '/' + action + '?' + params, callback, options, this.cache_time);


makeCachedRequest has been plaigarized from the Opensocial documentation and it’s very useful to bust the cache for requests. Also, notice this line for setting the content-type to JSON:

options[] =;

This is how we access that API, a code fragment:

authenticate: function(alias, mobile_no, password) {'user', 'authenticate',
		'alias=' + encodeURIComponent(alias) + '&mobile_no=' + encodeURIComponent(mobile_no) +
			'&password=' + encodeURIComponent(password),
login: function(orkut_response) {
	response =;
	data_success = response['success'];
	data_error = response['error'];

	if(data_success) {
		html = '<h2>Login Successful!</h2>';
		html += '<p>Welcome: ' + + '!</p>';
	} else if(data_error) {
		html = '<h2>Login Unsuccessful!</h2>';
		html += '<p>' + data_error + '!</p>';

	document.getElementById('mobshare_login').innerHTML += html;

Note that is automatically set by Orkut because you passed in the JSON content type; it parses the data received and creates a javascript object. Cool, ain’t it? It’s very easy to create a proper interactive Opensocial app this way.

OpenSocial and Facebook

A lot has been said about OpenSocial and Facebook, this is an attempt to say a bit more. As usual, a free-flowing list of observations:

  • Google uses Javascript as its base client-side language and extends gadgets with OpenSocial features. This I consider “good enough” but perhaps more importantly has a much lower barrier to adoption. The way a FB app is delivered (request-mapping, restricted FBML, fine-grained privilege control) feels much more professional, but at the same time a bit intimidating for newbies to the field. Libraries for almost all languages (esp. rfacebook) lower the barrier, but it’s never as simple as a .xml file which is mostly html and javascript (this is what a gadget is).
  • It’s currently not clear how OpenSocial apps communicate between each other across networks and how one app maps a user profile in one network to another. Without this, it’s mostly a single API which works across multiple containers in isolation. A single API that collates multiple containers is much more interesting.
  • Is there any set of UI guidelines? Is a gadget supposed to emulate the look and feel of its container or is it supposed to look the same across networks? Facebook provides extensive CSS classes and Javascript goodies (AJAX friend selector) to keep the experience uniform. I hope OpenSocial addresses this and soon.