The web has gone from integration via hypertext to integration via hyperdata.

A friend shared a recent C|Net article discussing the use of 404 error pages to feature missing children notices. Following links leads to a European effort to integrate information about missing children into 404 pages (and others, there's no restriction that it be on a 404). By signing up, you're offered some fairly standard HTML code to embed in the page. It's very similar to advertising integration.

So I jumped on over to the US' National Center for Missing and Exploited Children (NCMEC) hoping to find something similar or even better, an API. I was disappointed to find no real way to integrate the same data – not even simple dynamic HTML. All that data – all those children – are missing out on opportunities for exposure. Exposure that might mean being found.

API EVOLUTION

One of the things Google did right very early on was recognizing that API access would be a significant factor in the success of any web site. Now certainly Google's early APIs were little more than HTTP GETs or POSTs that could easily be integrated into other HTML which, on the surface, is really not all that innovative. After all, the entire concept of hypertext is based on the premise of linking together information using HTTP. But it – and others that followed like Facebook have continued to move along an evolutionary path that has graduated from hypertext to hyperdata – integration via RESTful APIs that return data, not HTML text, and enable usage and display of that in a format more suitable to the integrator and able to be integrated with other services such as maps or other sources of data.

That's important, because while HTML might be great for the web it's not always in the right format for the platform. Perhaps I'd like to be able to include a brief "child missing in your area" alert on any page – or in a header or footer or sidebar - that then links to more information, giving users the opportunity to find out more and serving the community but doing so in a way that flows naturally in my site or mobile application. I'd also like to localize that data, so as end-users roam so does information on which missing children are highlighted.

Widgets and gadgets – terms which are being appropriated by mobile now – used to offer one of several choices of formats, similar to the options presented to mobile users on tablets today. It's about size and style, but not necessarily about presentation and design. Data is displayed, for the most part, in a way the designer decides. Period. Integration options assume display choices and formats that simply might not fit with a site or ends up being ignored because it doesn't provide information in a format useful to the viewer.

AMBER alerts, for example, can be received via text messages now. But a text message doesn't necessarily help unless I'm really familiar with the area and have a good sense of direction. If the data were delivered in a simple standard format, it could quickly be displayed on a mapping application that showed me exactly where the child had gone missing in relation to where am I. But because the data is constrained, it's limited to a few zip codes per subscriber and alerts don't offer an easy way to figure out exactly where "9th and Maple" might be.

The lack of an API and a focus on hyperdata rather than hypertext, a focus on offering data rather than pre-formatted information, could mean missed opportunities. An application today that doesn't integrate well with others with a data-focused API would be considered too legacy to succeed, especially an application that purports to focus on sharing data. Such applications need to offer access to that data or it will not succeed.

In the case of web applications and infrastructure and social networking that may mean simply revenue left on the table. But in others, it may mean someone's child isn't going to be found.

That is a big deal and it's something that a hyperdata approach and API might actually help with, if it was given the opportunity.