The
API: From Hypertext to Hyper data
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 hypertext vs hyperdatausage 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.
For
further information visit: http://cloudcomputing.sys-con.
No comments:
Post a Comment