OK, I'm trying to take a Big Idea and make it as Simple As Possible to grasp.

If we link our JSON data together and use the same formats, then our mobile, browser and server apps can become much simpler - through clean, stable, common, shared, re-used code - and much more powerful - through clean, stable, common, shared, linked, cached data.

This is the second part in the Object Network series, which will guide you away from building isolated Web APIs to engaging in a linked-up data landscape.

It Just Takes Two

You're about to create a Web API.

All you have to do is to use Object Network formats to render your data, and to link it all up as an interconnected graph.

When the next person does that, they can link to your data. And you can link back to theirs.

You save the effort of working out how to design your API: you just use the pre-defined formats and protocols.

You don't have to replicate others' data any more in your own API, you can just link to it directly.

You should start to discover new opportunities within your mutually linked-up data.

 

Sharing and Re-using Code

You'll find yourselves sharing and re-using the code you wrote for server-side publishing and client-side interaction, both within your own project and on GitHub.

That open source server-side code may have adaptors from existing APIs and back-end systems into linked Object Network data. It may run in EC2, or use ql.io. Maybe the JSON is stored in a NoSQL database - and the Object Network formats fill the "schema gap" there.

That re-usable client-side code may be driven by link-fetching, and have built-in on- and off-line cacheing, pre-cacheing and change detection. It may render objects as widgets, maybe nested, maybe even as an endless network of navigable, cross-site data.

You may have a page assembler 'client' of this data on the server side, building your actual website from this cross-site data. Those pages would then be animated by the same data, pulled in by Javascript.

 

Example Part 1: Lanyrd

So let's take an example.

What if Simon Willison wrote the API for Lanyrd using Object Network standards. This would cost him very little. As an early adopter, there would be a little chatter, but I would do most of the work, as I'd be delighted to have him involved..!

So, what data? Well Lanyrd basically has events and people attending them. That's like iCalendar and vCard. The Object Network JSON format for them is called 'event' and 'contact', respectively. Simple.

An event links to various contacts, via lists of speakers and known attendees, and the address of the venue. Contacts have lists of links to the events they're attending and connections in their social network represented as links to other contacts. Still simple.

Note that I'm literally talking traditional HTTP links here, right in the JSON data that you get back from the Object Network interface. Something like:

"attendees": [ "http://obnet.lanyrd.com/134-134.json", .. ]

 

Example Part 2: Meetup

Now, along comes Meetup, who are also interested in publishing into the Object Network.

They also have events and lists of attendees.

Meetup don't have to do quite so much work to get things going, now, as there's an example already up and running and some of the wrinkles have been ironed out. Perhaps Simon open sourced some stuff.

But some of those events and some of those attendees are actually exactly the same across the sites (follow those 'events' links just above).

Bingo! We can link up the sites! We can link events and contacts across the two sites.

Update/elaboration - 21/1/12: We can start by just cross-linking the respective event and contacts that are equivalent. But over time, Meetup and other event organisers can point their events directly at Lanyrd users/contacts attending who aren't signed up to Meetup for some reason. And Lanyrd can either point directly at Meetup events instead of via their own copy, or be the main host of an event pointing at both Lanyrd and Meetup attendees.

We've shared code and understanding of our data and its links, we've brought developers together, we've linked and shared data. We've empowered and freed our users.

The sum is far greater than the otherwise isolated parts!

 

Let's Get Started

If we link our JSON data together and use the same formats, then our mobile, browser and server apps can become much simpler - through clean, stable, common, shared, re-used code - and much more powerful - through clean, stable, common, shared, linked, cached data.

It seems to me to be so obviously valuable to do this, that I'm having a really hard time understanding why I'm the only one that gets it so far! Hopefully this post has made it clearer than my previous attempts.

So, while I'm publishing this series of technical blog posts that will show exactly how this will work, why not get in touch so we can get the open Object Network moving right now?

I'm talking to you, Simon Willison!

 

Next: Object Network Basics.

Previous: Introduction to the Object Network.

Join the discussion in the Object Network Google Group!