IEEE Consumer Electronics Magazine - July 2015 - 87

descriptions into alignment if there is
sufficient interest just as we now use
USB as a common power supply.
The good news is that there seems
to be a convergence on the ingredients
in this soup that are giving us the
opportunity for an #APIFirst approach
as an alternative to the idea that we
need to build and maintain an app for
each purpose on each platform.

Restful APis And the Rise oF
JAVAsCRiPt oBJeCt notAtion
As a software guy, I want to be able to
take advantage of existing devices rather
than build new devices for each purpose.
In 1997, my solution was open interfaces
using XML. Today, the world is discovering open interfaces using Java Script
Object Notation (JSON) instead in the
form of RESTful APIs with OAuth.
These acronyms are inherited from
common practices in exposing services
for Web set. We can use the same
interfaces for machine-to-machine
communications.
The end points are identified by universal resource identifiers (URIs). The
URL also specifies the message format,
with hypertext transport protocol
(HTTP) being the most common. It is
similar to an e-mail message and can
carry content in any format.
A Web page is an HTML message.
For data, we use XML, which is very
similar to HTML. Using JavaScript,
programmers figured out that they
could modify the HTML document
dynamically to retrieve data without
going to a new page. This technique
became formalized as XMLHttp. Over
time, the use of XMLHttp has evolved
to become the standard way to provide
APIs for Web services and, increasingly, devices.
XMLHttp is simply a transport for
any message format. Today, it is
increasingly common to use JSON.
JSON is simply the object notation
from JavaScript:
{
"First": "Joe",
"Last: "Random",
"Age": 34
}

It is simpler than XML and more
readable. You might also recognize it as
the notation used for CSS in HTML. It
nicely maps into the class notation in
common programming languages.
Both JSON and XML are represented as text strings. You don't need special
tools to read them. Because we use
HTTP as a generic transport, the message is passed directly to the device or
service without depending on intermediaries. This is very different from protocols like Bluetooth, which depend on
every intermediary cooperating. In fact,
messages should be encrypted to protect
the end-to-end relationship.

The use of XMLHttp has
evolved to become the
standard way to provide
APIs for Web services and,
increasingly, devices.
JSON notation can also be used to
describe JSON objects. This is one reason for using TypeScript (a superset for
JavaScript). One can declare
interface Name {
First: string;
Last: string;
Age: number:
}
Integrated development environments can offer hinting and help manage code as it evolves and is shared
with others. They are a useful way to
exchange structured data over other
transports such as WebSockets (a bidirectional streaming protocol for
HTML5) and MQTT (a queued message protocol).
JSON is easy to use with various programming languages. For example, it is
a good match for anonymous types in
C#. Examples of programming languages are provided in [2]. The semantics of
the data are described using JSON [3]
("ld" in the URL cited in [3] stands for
link data).
Another part of this mix is OAuth [4],
which is a capability-like mechanism that

can be used in conjunction with HTTPS
(encrypted HTTP) for authorization.
OAuth is part of an evolving set of practices that are loosely coupled and is
becoming the norm for authorization for
Web services.
OAuth is a mechanism that does
not solve the problem of who you
should trust but provides one way to
give those you trust a way to present
credentials. This ability to evolve and
share is what gives this community its
energy and the ability to converge on a
common set of good ideas. The simple
protocols facilitate cooperation and
learning much as the Internet packet
protocols facilitate connectivity.
In addition to the sites publishing
APIs, we have sites like http://GitHub.
com with utilities and sample code that
take advantage of these APIs.
We are still at an early stage. Many
of the APIs go to Web sites rather than
directly to devices. This currently
works well enough because today's
Internet is too reliable, and we have
become overly dependent on being
connected all the time. As a result, we
cannot turn on the lights in our homes
if the Internet connection goes down.
We need resilience rather than brittle
dependencies. These dependencies are
also about business as we see companies trying to turn your door lock into a
service with a monthly fee.
OAuth itself is a mechanism for
trust relationships, but it does not dictate our policies. Note that I am using
the word trust rather than security to
emphasize that we need a far more
nuanced approach than secure/insecure.
We cannot just put a border around the
stuff we want to protect.
Trust relationships do not necessarily correspond to physical boundaries.
One well-publicized attack, on Target,
happened because the HVAC system
inside the security perimeter was compromised. In terms of APIs, a security
perimeter represents an implicit policy,
determining which relationships are
feasible and which are not.
If I want to turn on a light, it is not
enough to say "that bulb." I need to be
explicit and give the current network
address of the bulb and which network it
july 2015

IEEE ConsumEr ElECtronICs magazInE

http://GitHub

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