There’s some ways to get involved into OpenSocial
- Be the container
- Develop gadgets
- Develop a service that uses OpenSocial RESTful API
It is quite important to know architecture of OpenSocial whichever you choose. Especially when you choose to develop a gadget, there’ll be a lot of situations you get better result by knowing it.
This entry will try to explain what OpenSocial architecture is like by looking at reference implementation Shindig.
Relationship between gadget and SNS
Did you know how iGoogle renders gadgets secure? In fact, gadgets are rendered inside iframes which is on different domain.
The reason for that is, security. It is quite dangerous to have third party scripts on same domain because it could steal cookies, do XSS, etc. I’ve written an article about Caja and there’s some details about same domain security (sorry only in japanese).
Where’s APIs?
OpenSocial have 4 APIs People, Group, Activity and Persistent. Each of them is provided using RESTful in JSON, XML, AtomPub representation, or using RPC in JSON representation. Shindig’s JavaScript API is using RPC in JSON format.
I’ve mentioned about 2 domains on gadget architecture. In this situation, you know that API will be on Shindig domain because it’s using Ajax.
Gadget rendering process
OK. Now you know the basic architecture. Let’s take look at the gadget rendering process.
Choosing which gadget to render
First of all, you can’t render a gadget without request :) On iGoogle, user picks one’s favorite gadget from gadget directory, then display it on iGoogle page. The service has to render an iframe to display gadget, then, it needs to know what the gadget is like. Shindig has an API to return detailed information about the gadget. Metadata API.
Retrieving metadata
Receiving request to metadata API, Shindig looks at its cache first of all. If no cache found, it fetches gadget XML and returns information to the service.
Rendering iframe
Once getting information about the gadget, service will render an iframe to display the gadget. By doing this, Shindig will receive request to render the gadget.
Gadget XML’s contents will be rendered as it is basically, but it will be convinient if you know that:
- Specified features(tab, minimessage, etc.) will be concatenated and added to the HTML.
- External links to JavaScript, CSS, images will be replaced with cache url inside Shinidig if configured.
That’s all how gadgets are rendered. You can check that requests are sent to Shindig when trying out with Firebug.
External APIs
If you want to use External APIs, you can use gadgets.io.makeRequest. If you choose FEED as content type, JavaScript API will return abstract object as response regardless of content format(RSS, RDF or Atom). If you choose JSON, JS API will return JSON object even if the returned content is stringified.
You have a few choices on security too.
- Regular Request
- Signed Request
- OAuth
Regular Request is chosen when you don’t need any kind of authorizations on accessing API. Signed Request is OAuth Consumer Request in other words. By using it, external server can restrict requests from approved gadgets. OAuth is OAuth Core in other words. External server can know who’s accessing to the API using credential securely, on top of assuring that it’s coming from approved server.
Please refer to articles like this or this, I’ve written regarding OAuth. (If you can read japanese! :P)
Note that all external accesses are using proxy and Shindig has a strong cache functionality. You will have to take care of caches when developing a gadget. I’ll explain in detail about caches on coming entry.
(9)
(0)
(0)
(1)
Total: 10 
