IoT is eating the world: Developer perspective

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 Arduino, Raspberry Pi, and BeagleBone make it easy for the developers to get started with IoT. But sensors are only the tip of 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

Do’s and don’ts when developing

Hold your data in unstructured schemas

Choose a device agnostic platform, don’t model for certain kind of device. Don’t worry about 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. Gear up your platform for multiple devices.


Interoperability = Interconnectedness

Aggregation is not done in 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 manufacture 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 even well. This is where standards also come into play.

Optimize for small packets in high volumes

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

Handle failure conditions

Have good reporting and handling of errors, and a user interface. Did it fail or did it just go offline? Make sure you have good testing and error handling. Communicate status code breaking changes on end points, manage change and errors. Make sure you have in-depth logging. This will be invaluable and make sure devs can identify failures.


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 write a whole blog post about it and just scratch 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 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 for the space.

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.

Context matters

Gone are the days you say: heres 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 out human intervention. Keep in mind computational power. Understand common interface 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 (web hooks, 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% 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

Program Manager @ Google. I write stories around: Design, Community, Product, Sustainability, Philosophy, Work, Career.

Program Manager @ Google. I write stories around: Design, Community, Product, Sustainability, Philosophy, Work, Career.