Our physical and digital worlds are colliding. A new web epoch approaches — an era called the Internet of Things (IoT). In this realm, home devices, city sensors, smart cars, wearables, and every other device we use is connected to the Internet.

A benefit of this web-infused world is that humans will be able control and customize their universe via a personal device, such as a mobile phone. But some see hyperconnectivity as a negative, worried that phones and wearables — at least in their present state — only pose constant distractions to experiencing life. Another problem is that for the IoT to be viable, machines need a standardized method of communication. They will need to talk with one another.

Startups and large companies are pushing many connected devices to market. Gartner predicts that by 2020 25 billion connected “things” will be in use. These products look sleek on the consumer end, but behind the curtain, the industry is severely divided into two groups.

There are the device folks; the engineers that build the device, and the information design folks; the developers that create mobile apps that the everyday person will use. The problem is that the device folks are releasing many products into the market without much thought on standards for how the device is controlled, or standards for how it will talk with other devices.

Imagine driving through dense city traffic using roads without any lane dividers, crosswalks, or stop signs. It would be utter chaos. That is the reality of the current state of the IoT. There is a lack of holistic information design. We must standardize the flow of information to allow true machine-to-machine connectivity to arise, and thankfully, this can be achieved using APIs — REST APIs to be specific.

According to Brian Mulloy of the Apigee IoT lab, “crafting great APIs for IOT is an information design problem for the physical world.” To understand the importance of design standards, consider this historical example of how traffic controls were originated.

The First Cars in Detroit

Early traffic jam in Detroit

The scale of production that followed was tremendous. Many cars produced in Detroit were exported elsewhere, but a large amount simply stayed in Detroit. City infrastructure was not prepared at all for such a sudden massive influx of vehicles.

Streets, once a public forum with kids at play and slow horse-drawn carriages, were suddenly transformed into busy causeways. The city didn’t know how to handle the new technology — with no established design in place, roads became terribly congested. It became a public health issue when accidents and traffic related deaths become all too common.

Insightful citizens soon designed ways to standardize road behaviors. In Detroit, some of the first centerlines were laid. Pedestrian crossings were outlined, the first stop sign was erected, and the first red/green stop light system was put into operation. The city was evolving at a rapid pace, and with no government manual on urban traffic control in place until 1930, citizens had to design solutions to real world problems themselves, effectively becoming information designers.

Still in it’s infancy, the Internet of Things is at a similar stage in design. We are still learning what are the most effective controls and protocols to implement. The emergence of new types of machines with connected abilities means redesigning the way information is transmitted and intercepted.

What Does The Internet Look Like?

Visualizing the Internet. Source: Wikipedia. Under CC License.

It seems like a basic question, but depending on who you ask — and when you ask it — you may get an entirely different response. Things have changed a lot since the dawn of the World Wide Web in 1989 — an initiative originally meant to help CERN share information between scientists across the world.

To some, the term “Internet” still conjures up an image of a Yahoo.com landing page and search bar. For others, it is an interactive dating app on a mobile device. In technical terms, the Internet is a global system of interconnected computer networks. The Web, a part of that system, is a network of hyperlinked information transmitting data via the Internet Protocol suite, now enormous and diverse, allowing text, photo, video sharing to be instant, channeling commerce, permanently altering social communciation and dating, and more, integrating into every aspect of human life.

What Does The Internet of Things Look Like?

Today the Internet is made up of millions of networks linking several billion devices worldwide. So, the Internet of Things or IoT is simply an extension of that — more connected things. Or is it? Depending on who you talk to, you may get a different perspective on what ‘IoT’ is. According to Brian Mulloy of Apigee, you can group the IoT into three main categories:

1) Remote Control For Your Devices

From an individual user’s perspective, the IoT involves turning your smartphone device into a glorified remote control to manipulate your surroundings. Devices for lighting, music, thermostat, smoke alarm, security, laundry, bike lock, and more are becoming connected to the Internet. Many manufacturers in this space supply their own API programs — allowing third party developers to integrate the device with other devices or apps. Nest has sparked a whole ecosystem of integrations such as a red light notification system with LIFX that is triggered when a smoke alarm detects smoke. Examples include:

• Philips Hue: Home lighting
• Nest: Home automation
• GM: smare automobiles
• Centralight: on off switches

2) Wearable Computing

Wearable computing has seen a huge surge of interest lately. Different than mobile devices which many already consume (phones and laptops), wearables are literally worn, designed to monitor health, track athletic performance, experience virtual reality, and more. They take the form of headsets, glasses, bands, watches, sensors, and more. Some examples include:

• Google Glass
• Apple Watch
• Pebble
• Oculus Rift

The problem with having many connected devices in such close proximity is that you experience a “localized earthquake” whenever you receive a text message. Things just aren’t yet synced up correctly. Bluetooth isn’t as speedy as it needs to be, causing a watch to ring incessantly after a call is answered with the phone, for example. The way they are designed today, wearables seem like an unnecessary headache for the user.

3) Sensor Technologies and Machine-to-Machine Communication

From smart automobiles to energy utility savings, The IoT is also about device-to-device communication to pass time-saving and economic benefits down to the human. In the case of home automation, systems will be able to respond to local energy demand and peak usage times in order to save consumption for the user. The same process transfers over to other aspects of day to day life, in which we experience tedious tasks that could be made more efficient if the proper information design was in place.

Mulloy describes how his Old Ford Explorer has a leaky rear passenger wheel. Each tire has a measurement device that accurately monitors tire pressures, and transmits data to an onboard CAN bus, which circulates data throughout the vehicle. When refilling his tire at a pump station, he must manually use a hand meter to gauge tire pressure to avoid overfilling. This seems like a waste of time, since the car’s onboard system already knows the exact tire pressure. Wouldn’t it be ideal if the car could speak to the pump’s actuator to let it know when it had received enough air?

Populating urban environments with innovative machine-to-machine connections is the future of the IoT, but Mulloy notes that this needs to be implemented properly, with both manufacturers and software developers working together to develop standards.

Degrees of Separation Within The IOT

Given the hyper-connectivity of wearable computing, and the general lack of machine-to-machine interoperability in day to day life, do we have too much connectivity or not enough? What is the perfect balance?

Mulloy encourages us to consider the IoT in the terms of Kevin Bacon. Well, not Kevin Bacon, but the 6 degrees of separation game related to the actor. It’s inspired by Graph Theory, which considers the average distance between two points on a graph. Graph Theory is often used to cluster data within infographics and visualizations.

User interface and Hyperlink. These two facets are the foundations which make browsing the Web possible. On a graph, we would represent them with a node and an arc. Similarly, the IoT requires connections, but not between sites, but between machines.

When plotting connections within the IoT, nodes are devices and arcs are APIs. Arcs often lead to local hubs — home, user, energy hubs — which then lead to the cloud. If we were to plot the actors in our air pump example, we would place them very far apart, indicating a large diameter. With wearables, they are close in proximity, but are not in communication at an application level — the arcs are nonexistent. So, how do we make the diameter of the IoT smaller, and fill in the gaps?

Mulloy encourages us to model what has been happening on the social web. Users wanted a convenient way to display their Instagram photos on their Facebook feed. Thus an Instagram API was developed that allowed that to be possible.

We need to apply the same method of thinking to machines. A machine like an air pump service station should delegate user data in the same way a web app does, thus allowing the pump actuator access to read the car’s tire pressure given the user approves. This would be a true direct IoT connection, decreasing the space between nodes on our graph. Mulloy phrases it well when he says:

“A true Internet of Things will emerge from recombinant devices sharing data over Internet protocols and delegating authorization choices to people”

To truly achieve the IoT, we need data flowing over internet protocols and delegated authorization. In other words…

“We need a REST API for every device… that’s really what it comes down to.”

But encouraging the device world to embrace the API world will take discussion and effort. Entire ecosystems of technology will have to exist in order for us to solve these problems and create these connections, and security needs to be in place to properly manage identity and access throughout all integrations.

Forming an Ecosystem

The API world has known for some time now that the API is a product and the developer is a customer. This is true for IoT ecosystems as well. For a developer to create the link between an air pump and a car means we need an API for the air pump and an API for the car. The problem is that most device makers do not understand REST APIs.

Device people and software people come from completely different planets. The device folks, or “born to suffer” engineers as Mulloy describes them, are very keen on cutting unit cost. Therefore, they want to constrain resources for production. App developers, or “born to party engineers” are of a completely different mindset. With the potential to monetize access to large data sets, developers on the other hand want as much resources at their disposal as possible.

Device folks need to understand that the API is a product. Whether they like it or not, app developers will be their primary consumers. This means finding a happy medium between constraint and cost, opening more data and functions to the developer, and building APIs for their devices that understand the needs of their consumers in terms of design, and preferred protocols that mimic present web architecture.

REST API Design For Connected Devices

In his demo with Nordic APIs, Mulloy showcases a slew of awesome gadgets. A radio antenna, thermometer, motion detector, smoke detector, door switch, night light, and door lock — how would one possibly turn these devices into an API that a mobile app could manipulate?

Mulloy demonstrates how it is possible to remotely lock a door using a RESTful web app hypermedia client. His hypermedia client, using the Siren hypermedia specification, is used to issue API requests to the server. Simply sending an HTTP GET request is enough to unlock the door. A manual lock triggers the API state to change as well.

Once state is changed to locked, the device and API has only a single available action — unlock. This is great for an iPhone app, because it means that it doesn’t need to know much about the device. It just needs to know how to read the API and generate UI widgets to initiate calls. The demo shows that HTTP is a compelling protocol that should be embraced by device folks coming from a bus perspective.

Every Device Needs a REST API: Our Expectations Have Risen

Think about Detroit in the midst of traffic chaos before implementing the proper information design standards. With millions of new “connected” competitor products emerging on the market, we need to embrace standards to allow the IoT to be fully realized. As REST is so widespread in the API world, device manufacturers should realize this importance, and empower device APIs with the protocols best suited to accelerate adoption.

Machine-to-machine connections have the power to dramatically increase the quality of life. It’s true that as individual users, our technological expectations are increasing exponentially. Soon, we’ll move from a mindset of “shouldn’t there be an app for that”? to “shouldn’t I be able to control that thing?” Childlike dreams of telekinesis are nearing — who wouldn’t want to live in a magic utopia where objects just ‘get it’?

To enter this world, we must increase standards for machine-to-machine interoperability. Perhaps Mulloy’s API Craft and IOT Craft initiatives can help spark discussion around API design and crafting smart solutions to problems in the IoT. Whatever the avenue, API providers and consumers need to evangelize the API approach to designing the IoT and spread word to the masses.