IEEE Consumer Electronics Magazine - July 2015 - 86

Bits Versus Electrons

#APIFirst: How Things Speak
to Each Other
By Bob Frankston

ConneCted things

f we are to understand the world of
connected devices, we need to look
behind the surface of the Web to the
application program interfaces (APIs)
that are the building blocks for the services we use and the ways devices "listen." The hash tag #APIFirst emphasizes
the importance of this foundation.
The Internet is an outgrowth of the
intelligence in our computing devices.
We started interconnecting computers in
the 1960s, and by the 1970s, we were
extending local networks to form a
worldwide Internet.
With the Web, we used those computers to enable people to work together
whether they were in the same room or
across the world. It is a testament to the
success of that idea that we now think of
the Internet as just the Web.
Today, our devices are increasingly
becoming "intelligent" in the sense of
having computing capabilities. We can
now explore the opportunities created
by our ability to interconnect or internetwork things.
I learn by doing and have been discovering the joys of Web-inspired APIs.
An API is a way things speak to each
other. The term comes from the way programs talk to each other, and now those
conversations can happen between devices across the world.
Our homes (or at least my home) are
places where we buy disparate devices

Digital Object Identifier 10.1109/MCE.2015.2422853
Date of publication: 15 July 2015

86 IEEE ConsumEr ElECtronICs magazInE

july 2015

and expect them to sort of work together. You expect that when you buy a coffee maker, you can just place it in your
kitchen and plug it in without having to
engineer it to carefully work with all the
other devices.
We had similar flexibility in the days of
the component audio system (aka Hi-Fi).
In the 1990s, the consumer electronics
industry tried to take advantage of the new
computing technologies and created a new
protocol, IEEE 1394, to interconnect the
various audio and video devices. However,
it was a step too far because it had too
much application knowledge built into the
protocol, including tight timing requirements, which limited its ability to act as a
general transport.
Today, we still define point-to-point
connections using physical cables such
as HDMI cables, which work well in
the simple cases. As I wrote in my last
column, we now use software to define
the relationships instead of running
wires between each pair of end points.
With devices such as Apple Air and
Chromecast and protocols like the one
that Microsoft uses for projects, I can
connect any video source to any screen.
The key is simplicity-the kind of
simplicity we get by normalizing
everything to packets. We can then
send the packets over any medium.
Interconnecting all these various transports has given us today's Internet.
This thinking was the basis for the
paper [1] I presented in 1997 at the IEEE
Consumer Electronics Workshop in Singapore and led directly to my current
involvement and this column.

At that time, I was at Microsoft trying to figure out how to implement
home control systems with a simple
constraint-preserving the ad-hoc connectivity that we had in our homes and
simple consumer electronics systems.
The approach I took very much honored the spirit of the Internet in trying to
provide building blocks rather than a
single solution. I was not trying to be
prescient, but rather, as a programmer, I
wanted to be able to craft my own solutions. Again, this is the spirit that gave
us the Internet. People with programmable devices did not want to petition telecommunication companies each time
they wanted to implement a new capability or service.
The simple answer was to have an
open interface for each device without
trying to force it in a single framework
beyond that. If one video device says
that it displays the content of "Channel
508" and another identifies the source as
"HBO," we have a mismatch. These
inconsistencies crop up as we try to
interconnect devices. People can deal
with them, but if we want to type "Game
of Thrones" and just see it, we need to
have common practices. We use the
flexibility of software to program
around such mismatches. That's what
Google TV does by having a database
that it uses to match up the various ways
of identifying the content.
This is not always simple because
we cannot necessarily map a temperature, for example, into a comfort index.
However, over time, we develop common practices and bring the various

Table of Contents for the Digital Edition of IEEE Consumer Electronics Magazine - July 2015