Johan's blog

Communication between websites

The number of dynamic websites is exploding. But also, the definition of "dynamic" is exploding. We are not talking about updating content, but rather about integrating content and services from different sources.

The number of dynamic websites is exploding. But also, the definition of "dynamic" is exploding. We are not talking about updating content, but rather about integrating content and services from different sources. Standalone websites --- where all content and services come from a single source --- won't disappear immediately. In a number of cases, they might still be useful. However, dynamic websites where content originates from different sources are an efficient way for companies and organizations to put much relevant information online without the need of entering all content themselves.
I see an evolution from gathering content from different sources towards interacting with different content-providers. A dynamic website from the "previous generation" takes a Google Map, a Flickr Badge, some RSS feeds and mixes this with own dynamic content. And you can indeed make very interesting and attractive websites with this concept.

What we are seeing more and more, however, is the need for not only gathering content, but also interacting with this content. One of the best known examples of this is the Facebook developer platform. Developers write applications that don't simply take content from Facebook, but that interact with the Facebook platform itself (e.g. retrieve the friends of the current viewer).

At LodgON, we are seeing exactly the same with vibe, the music community we created for Poppunt. Last Monday, Poppunt launched Vibe On Air, a project where 3 vibe-bands are selected weekly by an expert, and they get airtime at broadcaster Studio Brussel.
Clearly, Vibe On Air needs to integrate with Vibe. The selected bands are bands that were registered on Vibe. Registered Vibe users can vote for these bands. If you click on a profile in the Vibe On Air site, you see the profile in the Vibe site. And so on. We had a number of possibilities when developing Vibe On Air:

1. make Vibe On Air part of the Vibe site. Ok, but what if a number of other projects is added later on (which is very likely)? And what about a vendor lock (should I care? Yes of course.)
2. synchronize the vibe database every now and then. Are we still in the nineties?
3. use SOAP web services for communication. Good idea, but we have a huge number of small interactions, and the SOAP overhead would be too big.
4. use a simple REST based API, provided by vibe, with (third party) applications acting as consumers

Clearly, we decided to use the last approach. This is exactly the direction OpenSocial is also pointing at. We didn't use OpenSocial at this point, since the vibe API is relatively small and uses music-specific stuff. But all options are open.

---