The Web of Things: The Supercharged Internet of Things

By Dominique D. Guinard & Vlad M. Trifa

The majority of Internet of Things (IoT) systems paid little attention to the issues of an open and large-scale system of heterogeneous devices talking to each other. This is partially because the IoT focused strongly on the lower layers of the networking stack (how data can be transmitted between actors) and much less on how to facilitate the development of new applications (how data can be collected, visualized, or processed). In particular, limited effort has been devoted to enable ad-hoc interoperability, and in consequence it is still difficult to build scalable applications on top of heterogeneous devices.

The reason for that isn't as much technical as it is commercial. Indeed, a plethora of protocols for the IoT have been proposed in the last decade by standardization bodies, industrial alliances, and vendors. In essence this is a good thing. But the crude reality is none of those standards has reached sufficient traction to be "The One" universal protocol for the IoT.

Today, if you want a smart house, at best you will have to buy all components from the same manufacturer. Because of this, your only option to control that system will be through the application that comes with it. If that application has been designed mainly for iPhone and isn't available on Android? Well, that's too bad. If that application is badly designed, is painfully slow, or doesn't have the features you need, you'll be stuck with it.

Figure 1: The problem with Internet of Things! (Image used under Creative Commons 2.5 license, source:

Put simply, the IoT we have built so far doesn't have very much in common with the actual Internet: a unique, open, global network where everything is interconnected. The Internet of Things of today should rather be called the "Intranets of Things," because it is a number of isolated islands of functionality that were not designed to talk to each other. Even though an increasing number of networked devices offer APIs to control and access data about them, a custom application still needs to be developed specifically for each of those APIs. This is the case not only because different devices have different functionalities, but also because each API is implemented using different application protocols and has a different data model without a shared and standardized language.

Indeed, the simplicity and openness of the Web and its standards (URL, HTTP, HTML, JavaScript, etc.) is likely what enabled the Web we know today. This "lingua franca" enabled any user in the world to read any other webpage without anything to install and has been a major factor in the success of the Web. By enabling Web pages, browsers, servers, and services to all speak the same application language (REST with HTTP) the integration of a large variety of content was incredibly simplified. The equivalent enabler has unfortunately not yet been found for devices and applications in the Internet of Things.

In this article, we will describe the limitations and problems with the existing approaches to IoT that do not prioritize an open, universal, and simple application layer protocol for devices. For each of those limitations, we show the benefits of using a Web of Things approach.

Easier to Program


The first problem with existing approaches is that many of those protocols are complex and difficult to use. Such a high barrier for adoption, just like the Internet had in the 70's, puts it out of reach for most people. Especially, learning to connect to various devices that use diverse interfaces and protocols is an arduous task that will deter the most tenacious amateur that wants to get start with programming his smart house. If you have any doubt on this, we invite you to consult the specifications of the ZigBee[1] protocol stack or of DPWS[2].


Using Web protocols to read and write data from/to devices is much simpler to use and faster to learn than the complex IoT protocols. Additionally, if all devices would offer Web API, the same programming model is used for any device. So, once you get the basic skills needed to build simple Web applications, you can rapidly talk to new devices with minimal effort.

Open and Extensible Standards


Another issue is that many of those protocols have been continually evolving, as new use cases are made possible by new technological developments. Because some of those standards are funded and governed by one or a limited number of large corporations, they might not benefit from the same level of neutrality as a community-led open-source project. Besides, the companies could decide to introduce breaking changes as they wish, therefore rendering existing devices and applications unable to talk to each other.

Moreover, some of those standards are not publicly documented and cannot be simply used and implemented without paying a significant annual fee, and their specifications are not publicly available, which automatically limits their adoption to only large industrial organizations. Closed and proprietary protocols also lead to vendor lock-in. Ensuring switching to a different vendor is really time- and cost-intensive is a very well-known business strategy for big software players, nothing new here. However, in an IoT context, the barriers are much higher as switching radio protocols often require hardware changes. Similarly, switching applications protocols requires firmware updates, which are hard to apply in the real world.


The reason Web standards have reached such popularity is because they are entirely open and free, so there is little risk that they would change overnight. They ensure that data can be rapidly and easily exported from any system, hence HTTP and REST is an great choice when one wants to offer public access to some data.

Fast and Easy to Deploy, Maintain, and Integrate


Because entire systems would need to use a single protocol, it requires significant effort to write custom convertors for each new device or application that needs to be integrated. Maintenance of such a delicate assemblage of custom code is a risky task and in business applications would mean significant investments.


There is no risk that "the Web will suddenly stop working and require an upgrade." Yet, the limits of what can be done on the Web have not ceased to be redefined in a decade, with the ability to capture images from a camera or share one's location. In contrast, there are always new devices and protocols in the IoT world, and each time one of the many protocol changes, all the other pieces of the puzzle that use the device need to be updated.

Loose Coupling Between Elements


The implication of the above is first of all a tight coupling between the devices and applications in the network. The system works well as long as all pieces behave as expected and are used as initially intended. Sadly, this does not leave much space for ad-hoc, unplanned interactions and repurposing of services into new use-cases, which is an essential requirement in largescale open networks of devices.


The HTTP protocol and generally the Web is loosely coupled by design because the contract (API specification) between actors on the Web is both simple and well defined, which leaves little room for ambiguity. This allows any actor to change and evolve independently from each other (as long as the contract does not change), that's why you can still visit a Web page that hasn't been updated since the early 90's (we'll skip the comments about its visual design…). The ability for devices on the Internet of Things to talk to new devices as they get added without requiring any firmware updates is essential for a global Web of Things.

Widely Used Security and Privacy Mechanisms

The issue of personal data, privacy, and security of IoT/WoT systems has always been a major concern when it comes to building and deploying real-world applications. The two angles to consider are:

  • Security: How to ensure a system cannot be easily accessed or used in a harmful way by unauthorized users or systems. In other words, this is about ensuring that no one can access data or a device he isn't supposed to have access to.
  • User privacy: Assuming security is in place and only authorized and authenticated parties or applications can access some data, how do we ensure that no private information about users (e.g., personal information, behavioral data—where the user is when, what the user is doing with who, etc.) could be accessed or derived from it? This is particularly difficult because even if a seemingly harmful piece of data available about a user is harmless on its own, when combined with another piece of data available from another sensor or system it can be use to unambiguously identify a user and it behaviors.

Truth is, even though there have been many projects and efforts to improve the security of those systems, as of today, the Holy Grail of security and privacy in the IoT world still remains to be found. The real complexity is that capabilities of the IoT are relatively new at this scale, and the risks associated with those technologies are both largely unknown and hard to identify or measure in real-world applications.


As explained earlier, because applications in the IoT are often developed individually, the security mechanisms for these deployments are too often written from scratch, not tested sufficiently in the real world or simply non-existing! Even today, a number of IoT devices are being deployed out there without using a sufficient level of security, dangerously exposing their authentication keys to the world[3]. This is mainly because IoT-specific security systems have quite often been designed to work well in closed eco-systems, where every element is controlled.


The Web can help here too. Looking back at the history of the Web, we have made tremendous progress in building usable and reliable security mechanisms and protocols. These methods are not bulletproof, just like no security system is, but a practical compromise between dependability, ease of use, performance, and availability.

The fact is that even today, it isn't uncommon to hear about a large and famous online company that got hacked and the data about millions of its users got leaked publicly. Even worse, protocols that have been held as very secure and trusted might still suffer from tiny unknown problems making them vulnerable when found (SSL Heartbleed[4] anyone?). With a few exceptions, as long as those systems are implemented correctly, the possibility to hack them through remains minor, especially given that those systems are used daily by billions of users. The advantage of using Web-based common standards, as opposed to custom and novel ones developed for the IoT, is that they have been and still are extensively used and tested. Many implementations of such systems are open source (e.g., OpenSSL), which means the code is constantly used, tested, updated, and fixed by thousands of developers. Leveraging such established methods reduced the risk of failures as opposed to the bleeding-edge (pun intended) techniques being developed from scratch for the IoT and which have been tested and used in the wild only marginally.

WoT—the Shortcomings

We realize that at this stage you might think: "this guy got a little carried away with his WoT!" It might be a little true, however, having worked for a decade in the non-Web IoT we can feel how much the Web can be a game changer and we explain and illustrate why in Building the Web of Things, published by Manning Publications.

Nevertheless, the Web of Things isn't the "Answer to the Ultimate Question of Life, the Universe, and Everything." As with every disruptive technology or approach, it comes with its own share of challenges. Security and generally data privacy is one of these. Connecting all Things in our physical world to the Internet and making them accessible on the Web also means we potentially expose them to intrusive governments, viruses or disreputable companies who could leverage this to run denial of service attacks or information mining against the real world. We should assume they will! Thinking about security is already a must for the IoT, and the WoT adds a few more concerns, especially on the data privacy side of things. A largely connected system will always be more vulnerable than an isolated one. However, a system connected using open standards is usually better off than one based on custom security mechanisms. Moreover, this isn't the first time we have to face such a dilemma: our computers could be isolated, but this would really reduce their range of applications. The IoT and the WoT are no exceptions: we, as citizens, have a choice and should put each of these new technologies on the balance between risks and benefits. The WoT should eventually be about making our lives easier and more enjoyable, not harder!





[4] Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs). See more:

WoT2 The Web of Things—The Supercharged Internet of Things

By Dominique D. Guinard & Vlad M. Trifa

This article is exceprted from Building the Web of Things by Manning Publishing.

Related Articles


  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date