With the expansion of the Internet of Things (IoT), and the diversity of products and technologies, the one thing that everyone agrees on is that it's time to start agreeing: the Internet of Things needs standards. Many agree that it needs open standards, like those that underpin the Web.
Obviously, a Web of Things is going to be quite different from the Web of Documents and Applications: it'll be much more fine-grained and much more "buzzy", with many sensors and actuators working together with many hubs and services. It's more likely to be at home with the next generation of the Internet Protocol: IPv6.
To meet the fine-grained and buzzy nature of the IoT, the Constrained Application Protocol, or CoAP, was created. CoAP is an open Internet standard for the Web of Things. It's based on the Web's core pipe: HTTP, but has many differences to allow it to be used by very resource-constrained devices and local radio networks.
CoAP can be used in many different ways, but there's a danger that a lack of clarity in exactly how it's used means it doesn't achieve its full potential to link up the world's embedded devices.
This article proposes a simple and clear way that CoAP could be used to build a uniform, global, decentralised Web of interacting and discoverable Things.
This article first appeared on the ThoughtWorks Insights pages. ...
With the expansion of the Internet of Things (IoT), and the diversity of products and technologies, the one thing that everyone agrees on is that it's time to start agreeing: the Internet of Things needs standards. Many agree that it needs open standards, like those that underpin the Web.
Obviously, a Web of Things is going to be quite different from the Web of Documents and Applications: it'll be much more fine-grained and much more "buzzy", with many sensors and actuators working together with many hubs and services. It's more likely to be at home with the next generation of the Internet Protocol: IPv6.
To meet the fine-grained and buzzy nature of the IoT, the Constrained Application Protocol, or CoAP, was created. CoAP is an open Internet standard for the Web of Things. It's based on the Web's core pipe: HTTP, but has many differences to allow it to be used by very resource-constrained devices and local radio networks.
CoAP can be used in many different ways, but there's a danger that a lack of clarity in exactly how it's used means it doesn't achieve its full potential to link up the world's embedded devices.
This article proposes a simple and clear way that CoAP could be used to build a uniform, global, decentralised Web of interacting and discoverable Things.
This article first appeared on the ThoughtWorks Insights pages.
CoAP's Interaction Model
In simple terms, CoAP says you should send an Internet packet (UDP) to request a device's data - a GET on a device URL - and then expect back a packet with that data, perhaps a sensor value. You can also push a packet of data to a device - a POST to its URL.
An extension to CoAP for observation allows you to keep on receiving back data packets following a GET as the device state at its URL changes.
Ways of Interacting and Programming
This simple protocol is actually quite unique in the IoT world. Most IoT approaches work through events and messages - sensors and actuators may be connected to an event stream or message bus. The model used to program Things reflects this: events and messages tend to lead to actions and commands, and thence to central control, either in a central server in the house or a service in the cloud. Central control tends towards silos and proprietary formats and application protocols.
CoAP's Web-based model of devices with their own URLs is quite different. The Web that CoAP belongs to works through decentralisation - empowering everyone to publish and link up to anyone else. These links encourage everyone to use the same formats for their data, leading to re-use and "mashability". The lack of centralisation and greater interoperability leads to greater freedom to quickly innovate and build on top of each other's data.
But since the event/action or message/command model is so familiar in the IoT world, many people will inevitably try to use CoAP in this way, and miss out on all the benefits that have been proven by the unprecedented scale of the Web.
And even if they do embrace the CoAP and Web model, there's still sufficient flexibility in there to allow various groups of people to go their own way and lose many of the benefits. For example, people still don't have to use links between their worlds and don't have to share the same formats. They don't have to use POST in exactly the same way to achieve dynamic interaction with devices. The way Web APIs have gone - to create thousands of isolated silos - is strong evidence of this risk.
Peer-to-Peer Programming of Things
So what way should everyone use CoAP? Well, like I said, people should at least link up in a Web and use the same formats for lights and dimmers and locks and temperature. And use the definition of those formats to guide the POST-side interaction models.
However, unlike the Web of large-scale documents and applications, of browsers and webservers and client-server asymmetry, the Internet of Things is an Internet of sensors and actuators and hubs; interacting devices which work as symmetric peers in a, potentially IPv6, mesh.
This symmetry and peer-to-peer interaction are embraced in the CoAP model and can lead to an interesting, simple and powerful approach to the Internet of Things, and to the evolution of the Web itself. There's an opportunity here to go one step further than the Web, through a simple and powerful programming model based on peer observation.
The Light Depends On The Light Level Sensor
For example, consider possibly the simplest IoT interaction imaginable: a light that reacts to a sensor measuring the ambient light level and colour temperature, by adjusting its brightness and colour accordingly, either to match or to compensate.
There are two peers - and we don't need a central controller. The light depends on the sensor. They both have URLs, so the light can link to the sensor. We are using CoAP, so the light can observe the sensor itself:
The light depends on the light level sensor. That's the simple, powerful interaction and programming model that CoAP allows us to use - if we allow Things themselves to be the observing client. The state of a Thing depends on the states of the other Things that it links to. You can also have other abstract, non-real Things interacting in the peer mesh, which we can still call Objects.
I won't go into detail here about exactly how CoAP would be used to achieve this: the URLs and payload formats and the use of GET, observe and POST that enables Things to be client observers. I'll document that elsewhere, but it'll be based on my FOREST architectural style and the Object Network.
Things Watching Things
The Internet of Things can be a mashable Web of Things. If we're going to use CoAP to build that fine-grained, "buzzy", decentralised Web, then we should use it like the Web: we should agree on the formats for device data, and link up all of our Things and non-Thing Object data via their URLs. The common formats should also define how POST is to be used. That's the basic requirement.
We can then take a bold step further by exploiting CoAP's observation mechanism, to build a symmetric peer mesh of Things and Objects that link to, watch and depend on each others state: simply by allowing Things and Objects themselves to be the observing clients. That's all I'm proposing - that Things just watch each other instead of being observed by invisible processes.
This is a peer-to-peer model, where every player in the IoT is autonomous: empowered to control itself and to evolve its own published state independently and concurrently. That can create a global, visible, loosely-coupled peer mesh of mutually-observing, interoperating and co-operating Things and Objects.
Programs to animate these peer Things and Objects can be extremely simple: you only need to describe how their new state should be set as a function of the states around. This is similar to programming a spreadsheet. It's also an inherently concurrent and distributable programming model. My Cyrus programming language is designed to express this kind of program.
After filling up that other blog recently with 61 pages of content, one page a day, I was challenged by my ThoughtWorks colleague, Andy McWilliams, to help him get in more easily to my explanations of the Object Network applied to Augmented Reality and the Internet of Things, especially around how my approach differs and is better than other approaches. ...
After filling up that other blog recently with 61 pages of content, one page a day, I was challenged by my ThoughtWorks colleague, Andy McWilliams, to help him get in more easily to my explanations of the Object Network applied to Augmented Reality and the Internet of Things, especially around how my approach differs and is better than other approaches.
Here's the short overview I came up with:
Other Approaches
Broadly-speaking, existing approaches to unifying the IoT (AllJoyn, OpenHAB, The Thing System, Nitrogen, Argot, ..) are built around event and action messages. Messages are often managed through a message bus and/or an API that gives message construction and a function-call and callback interface, perhaps through socket connections.
Programming is offered through "event-action" (or "callback-call") rule programming, perhaps in Javascript or via a visual programming interface like If This Then That.
The Object Network Approach
The Object Network, on the other hand, is built like the Web, using URLs. These URLs point not to Web pages but to JSON state objects. Any peer can publish state objects on URLs - e.g. sensors, controllers, mobile devices, servers, etc - and that state can be pulled or pushed at any time between peers using HTTP GET and POST (or CoAP!).
Object Network programming is based, not on events and messages, but on state and state transfer. So instead of event-action rules, it has "state-to-state" rules, which are simpler and more powerful. Actions, if needed, are handled by creating "intent objects", but peer objects are very much more empowered and independent, so can run their own rules to set their own state in the face of surrounding state objects observed through their links.
Three Object Net Posts
I then pointed Andy at one of the posts on that other blog, but here are three posts there that are relevant:
Benefits of The Object Net Approach
These posts give more elaboration around the benefits of this approach, but briefly:
Using URLs is a force towards harmonisation of the formats they are contained in - each end of the link will tend to come from the same family of formats. So simply putting URLs in JSON is itself a massive benefit, if it leads to common formats for the same data. Further, these links and shared formats, when used across multiple systems, form a "fabric" of data that can be used to serendipitously create whole new applications and mash-ups.
It's a simple and powerful distributed systems model, as the Web itself has demonstrated. When it becomes peer-to-peer and asynchronous through CoAP, IPv6 and the IoT, its power increases further through timeliness and interactivity, decentralisation and the removal of intermediaries - and puts that power in the hands of users in their intimate daily lives.
To this the Object Net adds the simple and powerful programming model of setting object state as a function of surrounding neighbour, environmental or public object states, observed through links. The key aspect is the autonomy of each object in the network to determine its own state evolution in a decentralised, loosely-coupled mesh.
CoAP-based Alternatives
Now, merely using the CoAP stack buys you most of the above approach, being chartered from the start with REST in mind, plus adding asynchronous resource observation and having great peer-to-peer potential through IPv6 and UDP.
So really, it all depends on the code that uses it - does it build the observation model into the programming model like the Object Network does? Does it simply let you describe how the state of your object can be set according to the states of objects you link to and observe? Does it talk about common data formats? I've yet to track down a framework or platform that does this.
The nearest I've seen to an approach that has many of the elements of this, including observation through CoAP and a model layer above, is the Open Source Internet of Things (and see here also). This project seems to be much more complex, partly due to its being based on the Semantic Web.
I'll be exploring how the Object Net compares to it and the overall CoRE approach, and maybe also see how the IPSO Alliance and other initiatives fit in to all that.
I've started another blog called Building The Object Network, about how I'm experimenting with Augmented Reality for the Internet of Things using the Object Network approach.
So far I've been blogging every day.
Do subscribe! ...
I've started another blog called Building The Object Network, about how I'm experimenting with Augmented Reality for the Internet of Things using the Object Network approach.
So far I've been blogging every day.
Do subscribe!
Well that worked out pretty well: I have a 3D environment on Android programmed in a simple but powerful declarative language which I've called "Cyrus".
Cyrus basically uses JSON all the way through: from user interface and scene graph to rewrite rules, on the wire and on disk. The Cyrus programming language is essentially JSON itself, as JSON rewrite rules. I've reduced the noise of JSON in Cyrus by taking out redundant double-quotes, square brackets and commas. It looks very nice to me. ...
Well that worked out pretty well: I have a 3D environment on Android programmed in a simple but powerful declarative language which I've called "Cyrus".
Cyrus basically uses JSON all the way through: from user interface and scene graph to rewrite rules, on the wire and on disk. The Cyrus programming language is essentially JSON itself, as JSON rewrite rules. I've reduced the noise of JSON in Cyrus by taking out redundant double-quotes, square brackets and commas. It looks very nice to me.
The Name Cyrus
Now, probably to everyone's confusion and annoyance, I'm always thinking of multiple names for the many things I create around the core principles I'm evangelising. And then changing them all the time!
So I decided to choose a single new name, "Cyrus", for everything, and will endeavour to stick with it this time... I got the name from playing around with the letters of 'cyberspace rules', but will probably claim it stands for "cyberspace rules updating state" or something, because that sounds more impressive.
One advantage of this name is that both academics and regular folk should be able to spell it!
So now NetMash and Fjord are the "Cyrus app" and the "Cyrus programming language" respectively; the Object Network is now just the Cyrus network - a Web of JSON.
Once I have rough consensus and running code, it'll all be exchanging data via the Cyrus Media Type - probably "text/cyrus" for the simplified form and "application/cyrus+json" for the noisy one.
The basic underlying model and architecture implemented in Cyrus are still called "Functional Observer" and FOREST, however.
The Future of Programming
Edd Dumbill has recently described how he sees the Future of Programming.
In that article, Edd offers five categories that he sees as forces driving this, which I'd paraphrase as: concurrency within and between machines; embedded and mobile hardware; data-oriented programming; end-user programming; simplifying the software stack.
I was pretty excited to read this, because it accurately describes the drivers behind Cyrus.
Cyrus in 2013
So I'm now going to spend 2013 explaining to everyone why Cyrus is the next programming language they should try out. And, like I said before, I mean everyone - from kids to grannies, via Business Analysts.
Cyrus is, of course, very new, but even while it's maturing this year, it will still be good for non-critical uses, such as prototyping - especially mobile or distributed apps and sketching out business rules - and for making little fun apps, maybe while learning to program.
Do join the Cyrus Google Group if you want to get involved in any way, or just post a comment below.
Right, let's get started with some basic conventions in the Object Network!
This part in the Object Network series will cover URLs, HTTP headers and some common JSON patterns.
Updated 23/1/12: I changed the URLs in the example to have one of each type. ...
Right, let's get started with some basic conventions in the Object Network!
This part in the Object Network series will cover URLs, HTTP headers and some common JSON patterns.
Updated 23/1/12: I changed the URLs in the example to have one of each type.
Example
Here's an example interaction with an Object Network interface:
GET /events/uid-f330a3-4011e.json HTTP/1.1 Host: mobiconfs.com If-None-Match: "32" : HTTP/1.1 200 OK Cache-Control: max-age=1800 ETag: "33" Content-Type: application/json . { "is": "event", "title": "Over the Air 2011", "content": "Top Mobile Meetup at Bletchley Park", "start": "Fri, 30 Sep 2011 09:00:00 GMT", "end": "Sat, 1 Oct 2011 23:00:00 GMT", "location": "http://bletchleypark.org/address.json", "attendees": [ "/staff/uid-55d3.json", "uid-06-7d5d" ] }
So let's start from the top...
URLs
The full event URL is http://mobiconfs.com/events/uid-f330a3-4011e.json
, which has
a host part, a path prefix, a unique id for this object, and a file type suffix.
Of course, being a URL, none of this is significant from a resource identifying or locating point of view. Any sequence of characters that can be used to find a JSON object will do.
But it will help our routing and debugging to have some handy keywords in the path prefix and it will help our debugging to have a JSON suffix when playing with files.
If we use a JSON database or a relational database, we probably have a UUID or GUID to index and retrieve the object, which can be used in the URL. If we find the object by query, it's possible to pack the query terms into the URL instead.
We avoid actual query strings in the URL because we want to be sure that all caches will work! Also, we don't put auth tokens in the URL, we put them in the headers, as otherwise we fail to identify a real resource with orthogonal access control.
But the most important thing to remember is that the structure of our URLs isn't part of the domain or resource model - it is not significant to clients and we can change it at any time. There are no URL templates or query 'forms' in the Object Network. Our public resource model isn't in the URLs, it's in the JSON formats and the links between objects.
HTTP Headers
There's an integer ETag here, which could increment with every change in object state. Rather store the ETag with the object than calculate the ETag every time from the content, as that could slow you down. ETags are used for both saving network traffic and for change detection. Their use is expected behaviour in the Object Network.
As is the use of Cache-Control; use max-age, not Expires. Always set it, even if you set it to a month or a year, or zero. Get into good habits now and write the code you need, for this and for ETags. In other words, record when your objects change and know how often that happens.
The Content-Type - the Media Type - is application/json
. The Object Network is only
defined for JSON. This blog page forms the foundation of an Object Network Media Type
based on JSON that we'll be defining when we reach
rough consensus and running code. Individual object
types, such as contact and event, are defined on top of the base Media Type,
Microformat-style.
The return code is only used to guide or report on the success of data transfer; it's not used in the Object Network for anything at the domain level. So 200 if transfer succeeded, 303 if it's somewhere else, 304 if it's not changed, 404 if it's not found. We won't need much more than that for now.
JSON Types
Looking inside the JSON, we offer one or more tags asserting what kind of object this is intended to represent - the example above "is" a calendar "event". But clients are free to ignore that and interpret the object or its elements any way they like.
There is a selection of possible types, such as "event", "contact", "user", etc. Plus special tags: "list" and "query", for lists of objects and queries on those lists. For example:
"is": [ "user", "list" ]
or "is": [ "contact", "query" ]
An object may be the union of multiple types, such as "is": [ "contact", "event" ]
,
or a 'subclass' with an extra "is" tag and extra fields in the object. If there is
only one tag after "is", as in this example, the list brackets are optional.
The semantics, if not the exact syntax, of certain fields in the JSON will usually be declared in the Object Network as being defined in some other standard - in this case iCalendar: "start" and "end" map onto "DTSTART" and "DTEND".
Most fields in the JSON will be defined within the type or format that an object "is", but many will stand alone. For example, "title" above is something that will mean the same in any format, as will "location", and other common fields, such as "created" and "author".
Almost by definition we don't have namespacing in the Object Network. The whole point is to encourage discussion and agreement, not isolation.
JSON Links
Above, "location" indicates a link to another object; just an absolute URL inside a
string, which points to an Object Network object on another domain. The "attendees" list
has two relative URLs, the first with a full path, giving
http://mobiconfs.com/staff/uid-55d3.json
.
You can also just put the UID there and let the client put the same relative prefix on
and attach ".json" on the end, as in the second attendee above:
http://mobiconfs.com/events/uid-06-7d5d.json
(maybe that was the organiser, and
their URL paths or routes are kept with the events).
It's at least an Object Network convention, and possibly a requirement, that links start with "http://", "/" or "uid-". It may then be useful to add "./" to that list for relative URLs not starting with "uid-". Fully-expanded absolute URLs, starting with "http://", have the advantage of allowing the containing JSON to be directly exported and used independently of its own URL. Absolute URLs can also be detected and rendered as active links in browsers, using a plugin such as JSONView, and in email clients, etc.
List and Link Transparency
A wrapping list isn't only optional for single "is" tags. This rule applies within all Object Network JSON. For example, one email address in a contact needn't be put into a list of one. A corollary of this is that, when pattern matching, a single item will match that item anywhere in a list.
Also, in the Object Network, a link to another object is logically the same as replacing that link with the object itself. In other words, a pattern match will transparently jump over those links and into the linked object's content. It is therefore also valid syntax to directly include, rather than link to, an object.
Links to list objects are also seen as the same as inline lists. For example:
{ .., "email": "uid-111", .. }
where uid-111
is:
{ "is": "list", "list": [ "a@b.com", "c@d.com" ] }
is the same as:
{ .., "email": [ "a@b.com", "c@d.com" ], .. }
This allows lists to be grown outside of their containing object, or reduced back in again. An object can switch at any time between these forms: single-to-list-to-single, link-to-inline-to-link.
There are no nulls or empty lists in the Object Network, or rather, null and empty list are equivalent to non-existent. So:
{ a: [ null ], b: [ null, c ] }
is the same as:
{ b: c }
Linking into the Object Network
Here's one way in: put something like <link rel="object-network" href="/events/uid-f330a3-4011e.json" />
into a Web page to point to the Object Network JSON version of an event, blog post, contact page, etc.
Or just have an in-page link, and rely on the client responding correctly to the Media Type.
Next: The Object Network Contact Type.
Previous: Why we should link up our Web APIs.
Join the discussion in the Object Network Google Group!
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. ...
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!
It's interesting to compare the current growth of Web APIs with the early growth of the Web itself. To save you jumping those links: the Web dramatically beats the APIs.
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. ...
It's interesting to compare the current growth of Web APIs with the early growth of the Web itself. To save you jumping those links: the Web dramatically beats the APIs.
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.
What Formats?
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
PRISM or
Dublin Core, for example.
Looking around some more, there's RFC5988
which can give us our labels for some handy JSON links: "copyright":"http://.."
, etc.
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.
Next: Why we should link up our Web APIs.
Join the discussion in the Object Network Google Group!