Dos and Don'ts for IoT Development

I wear API colored glasses. Internet of Things (IoT) is more than a buzzword. The convergence of devices, cloud, and analytics is creating a perfect storm for the developers. APIs make it easy for developers and partners to securely access devices and build ecosystems around them. Web APIs, or more specifically REST APIs, are key for connecting devices to the Internet.

Cheaper sensors, affordable prototyping platforms, like the Arduino, Raspberry Pi, and BeagleBone, make it easy for the developers to get started with IoT. But sensors are only the tip of the iceberg.

Developers need to deal with a variety of data sources, such as object storage, semi-structured NoSQL databases, and RDBMS, to store and process sensor data.

Building Blocks of IoT Development:

• Devices, endpoints
• Device management — collecting information, storing it, and extracting it
• Filtering — information filtered out, event handling, and notifications
• User management — permissions, users, access, roles

Dos and Don'ts for Developing

Hold Your data in Unstructured Schemas

Choose a device-agnostic platform. Don’t model for a certain kind of device. Don’t worry about a structured schema that is a closed fit, rather choose flexible schema. A relational database is constrained, rigid, and doesn’t allow for all changes you want. Therefore, you need to gear up your platform for multiple devices.

Interoperability

Interoperability = Interconnectedness

Aggregation is not done in a silo. Be open. Share data between the device and the people interacting with it. People find creative ways to interact with devices and data.

For example, think about if every manufacturer had a different electrical outlet in the wall. IoT is similar in that we are going to collect a lot of unique IoT things, and if everyone builds their own “world,” it won’t work together, or well. This is where standards also come into play.

Optimize for Small Packets in High Volumes

You may have constrained networks and resources. You must offer ways to pass in information in a structured and minimalist way. Volume becomes important when connecting a lot of devices.

Handle Failure Conditions

Have solid reporting, handling of errors, and a user interface — did it fail or did it just go offline? Make sure you have strong testing and error handling methods. Then, you need to communicate the status code breaking changes on endpoints and manage change and errors. Not only that, you need to make sure you have in-depth logging. This will be invaluable and make sure devs can identify failures.

Documentation

Don’t neglect documentation!

Start Small

Reduce TTFHW (time to first "hello world"). When developing for the IoT connect device, plan for growth and change. Don’t rush. Think about all aspects of it, from its payload size, messaging, and frameworks, to the device capabilities.

Security Matters

I’m going to keep this one brief, even though it’s a juicy one, because I have written entire blog posts about it and just scratched the surface.

It’s a simple idea, but if the device is secure, you should trust your device. Some security best practices: provide transport layer encryption, provide a permissions model for you to secure access, and allow you to encrypt messages with public-private keys.

Standards

Standards folks and open-source folks don’t usually get along. But, standards are a necessary evil.

We can’t all go out there and start building our own unique vertical solution and put a wall around it. But, we can build our vertical solution on top of open-source horizontal standards. Standards and collaboration are required to enable this massively smart and interconnected world.

Each day, more and more devices are coming online, adding to the ever-growing Internet of Things (IoT). Analysts agree the IoT will grow to many billions of devices over the next decade. The challenge for the IoT ecosystem is to ensure these emerging IoT devices can connect securely and reliably to the Internet and to each other. That’s why the work that folks, like the Open Connectivity Foundation, are doing is very important.

There are a lot of emerging standards out there, but I would like to briefly highlight the Open Connectivity Foundation (OCF). OFC is a group of industry leaders who will be developing a standard specification and certification program to address these challenges.

(OCF) Standards will unlock the massive opportunity in the IoT market, accelerate industry innovation, and help developers and companies create solutions that map to a single open specification. OCF will help ensure secure interoperability for consumers, business, and industry.

Billions of connected devices (devices, phones, computers, and sensors) should be able to communicate with one another — regardless of manufacturer, operating system, chipset, or physical transport.

The IoTivity project is sponsored by the Open Connectivity Foundation (OCF). The IoTivity project was created to bring together the open-source community to accelerate the development of the framework and services required to connect these billions of devices. IoTivity is an open-source software framework, enabling seamless device-to-device connectivity to address the emerging needs of the Internet of Things.

What Will it Look Like?

• Open
• Royalty-free
• Seamless
• Technology agnostic
• Fair and accessible
• Cross-industry
• More secure
• Structured

Standards and Collaboration Drive Adoption

• Wi-Fi: $90 B in annual economic value in the US
• OSS 31 billion lines of code: 3.8 million OS contributors
• Mobile 2015 4 billion unique subs — Contributing $3.7 to global GOP
• Web: 1995 <1% of the world connected: 2016 — over 40 percent connected

Context Matters

Gone are the days where you say, "Here's a REST client with basic Auth."

Don’t think that only one person or device will be consuming. A lot of times, it's two machines speaking without human intervention. Keep in mind computational power. Understand common interfaces across protocols, and design your API knowing what will matter.

Ask yourself: who is consuming your APIs and your IoT device? Keep in mind that not every device will communicate over REST; devices have different form factors and computational power. Devices also may communicate over multiple protocols (3G, 4G, CoAP, MQTT).

State Matters

• Provide ability to push state (webhooks, event streams)
• Provide ability to pull, or polling, state (REST)

Not all devices communicate over REST. State matters —and REST is the most common pull state, even though REST is stateless. Decide whether a Pull or Push state makes more sense for your project.

So, why Pull vs. Push? For self-driving cars, you’d need automatic responses, meaning you have high-time sensitivity. Push (regular API) is best in high-time sensitivity. REST is not literally instantaneous and response time is based on many factors, such as network, latency, size of call. But, REST works for most developers, and if you have low(er) time sensitivity, keep in mind, it can be as low as milliseconds. 90 percent of IoT devs are going to be OK with REST.

But, devs can get into trouble with polling when they want really fresh data. How frequently are you going to check for updates? Once per second? Ten times per second? On an API with lots of resources and thousands of clients, this can quickly become a scaling problem for back-end servers, not to mention the wasted data transfer. In fact, our friends at Zapier found that:

98.5% of all polling seen through their system amounts to wasted traffic