How the Internet of Things is Resulting in Non-Traditional API Communications Models

Just for kicks, something I like to say when discussing the Internet of Things (IoT) is that “there’s no such thing as a thing on the Internet of Things without an API.” This statement is somewhat orthogonal to another conversation which is that there’s really no Internet of Things yet; but there are plenty of separate networks of things (see In Alienating Developers and End-Users, Are IoT Vendors Headed for a Trainwreck?). It is a bit of trainwreck and for now, most IoT vendors prefer it that way. But, back to the API bit, it’s true. All these so-called things have APIs. Some documented. Some not. Some are Web APIs. Some are proprietary. They all have to talk to something across a network. Otherwise, why connect them?

But what’s even more fascinating to me is the diversity in the various master-slave communications architectures that are turning up. “Master-slave” may not be the best phrase to describe the communications models at play. But if you indulge me in this conversation, it doesn’t matter. This conversation isn’t necessarily about what protocols like HTTP, JSON, MQTT, or CoAP are conspiring to serialize and deserialize whatever bits and bytes are being sent to and/or from a thing. There are standard ones and proprietary ones at play. It’s mainly about what these things are ultimately talking to and what circuitous routes those communications are taking.

Let’s take fitness bands that go on your wrist. There’s data on those things, and in most cases, that data is accessible to developers through networkable APIs. Most APIs that are accessible over the Internet also need something called an endpoint that’s on the Internet. Sort of like the way that your home needs a mailbox that’s on a mail courier’s route. It’s the “place” where inbound and outbound messages to and from the API are exchanged. So, for something, like a fitness device on your wrist, where’s the endpoint? 

In the case of Web APIs — which a great many so-called things support — an endpoint is essentially powered by a Web server. You know, the same thing that makes a Web site work? Now, as Web servers go, there are ones that take up lots of compute power, memory and storage. And then, there are ones whose footprint hardly takes up any compute resources. But when I learn of a new “thing” that’s going to be on the IoT, the first question I ask is, “Is there really a Web server in that thing?” In a great many cases, the answer is “no.” 

As it turns out, many connected things are not really physically connected to the Internet of Things. In most cases, they’re not even connected to the Internet! Fitness bands, for example, are invariably connected to a smartphone over Bluetooth. The smartphone serves as a local proxy for the data that's going to and from the fitness band. The smartphone in turn is connected the Internet. But even it usually isn’t running a Web server and therefore, the endpoint for the fitness band isn’t on the smartphone either. So where is the endpoint? 

It’s in the cloud. Since your smartphone is on the Internet, it can transfer the data it has to the fitness band manufacturer’s cloud. A cloud where there is a Web server, and therefore an endpoint that developers can reach in the course of building apps that must consume that data. This does not preclude the fitness band manufacturer from also making an SDK that makes it possible for developers to develop a mobile app that runs on the smartphone that’s connected to the fitness band in such a way that app has no need to go to the cloud for its data. After all, it’s right there on the smartphone already (or easily retrieved through the Bluetooth connection).

The typical fitness band IoT communications model is a pretty common model. But there are others. For example, when I heard that selected Sony cameras came with an API for remote control purposes, I asked the obvious question; where’s the endpoint? Believe it or not, Sony cameras are actually running a little Web server in them!

Workflow diagram that shows how the Sony Camera APIs work

Generally speaking, this is for remote controlling a camera over a local area network. For example, I could imagine working at a company like Pixar and writing a mashup that, with one command, starts a camera moving on a track (around a subject) while activating its video recording capability at the same time. But if you’re clever enough, you could probably remotely control a camera from far away, over the Internet.

The more I come across supposed IoT things, the more I’m fascinated by their communications models. More recently, I received an announcement regarding a Kickstarter project for the Das 5Q; a “cloud connected keyboard." That certainly caught my eye. I mean, it’s one thing to have your run of the mill Bluetooth connected keyboard. But a keyboard connected to the cloud? What on earth for? And how? 

Once again, I reached out and asked “Does it have a Web server in it?” Once again, the answer was “no.” Somewhat like the fitness bands, the keyboard has a local proxy. But this time, it’s the desktop computer that it’s connected to. And unlike the situation with most fitness bands where the endpoint is up in the cloud, the endpoint for a Das 5Q is on the desktop that the 5Q is connected to. In other words, installing a 5Q also results in the installation of a Web server onto your desktop or notebook computer.

David Berlind is the editor-in-chief of ProgrammableWeb.com. You can reach him at david.berlind@programmableweb.com. Connect to David on Twitter at @dberlind or on LinkedIn, put him in a Google+ circle, or friend him on Facebook.
 

Comments