I believe that the most likely cause of such relatively slow growth (in what should be a booming ecosystem) is that each API forms a closed silo and cannot benefit from any network effects. Every API is different and there are no links between them. There usually aren't any links within a silo. You can't even use a given API without first consulting the documentation.
The Object Network is designed to fix this, with linked-up JSON in common formats. This will allow easier mashing, sharing and cacheing of data and allow client code to be shared and reused.
The Web Isn't APIs
Imagine if, back in the early 90s, you had to write a new client or download a new plugin for every website's "publishing API" - if programmers first had to read the documentation before they could get access to that particular website's content.
And imagine that there were no links between those websites - well, there'd be no point in having links if you didn't know what to expect when you got there - without first knowing the "API".
It's unlikely we'd have seen the phenomenal growth that the Web enjoyed. Google built a multi-billion dollar industry on those links between compatible sites.
HTML for APIs
Web APIs should be able to learn from the Web that they seem so keen to join. So how can we take these Web APIs and make them work like the Web does?
What's needed is something like an "HTML for APIs" - a format for data sharing and linking that all interested sites can publish in. This would allow easy linking of data between those sites, and clients that could work against any server they encountered by following those data links.
Now, API builders generally like to use JSON or XML for their data, but that's as high as they go up the shared semantic stack. They can do whatever they like inside that JSON or XML - but linking and re-using common types are hardly ever included in those things.
So that's where the Object Network comes in. It defines JSON formats for various common data types, and the links between them.
Well, we can start social, since that's where most of these Web APIs started. So we'll need contacts - based on vCard, of course - events based on iCalendar, news and messages in a JSON form of Atom, etc. Events will link to the contact objects of their venues.
Even though we have contacts, we'll still need objects representing users. A user is more dynamic than their linked contact card, including messaging status, GPS location and so-on.
We'll need comments linked to that news and reviews of those events. A review will link to the user reviewing and the restaurant contact or gig event being reviewed. We will need media metadata for pictures and videos, linked from any of the other types.
Finally, any of the above can be bundled into lists. In fact, a feed is just a list of news items. A gallery is a list of pictures. An address book a list of contacts.
Plundering and Interacting
We could also scan over some Microdata formats
for ideas. We could even plunder the Semantic Web for useful types: we could derive our
publication metadata formats from
Dublin Core, for example.
Looking around some more, there's RFC5988
which can give us our labels for some handy JSON links:
Once all that's in place, we may need to run searches or queries over those lists. And of course, allow events and notifications and update requests, etc. But that's looking quite far enough ahead for now...
How to Join the Object Network
This is the first of a series of articles discussing how we could go about building this Object Network - how we could launch a new network of shared data to replace isolated Web APIs.
Join the discussion in the Object Network Google Group!