Access: Web APIs for Things
1. Request an upgrade to
WebSocket 2. Use the “wot” sub-protocol inside the data frames 4. Upgraded to WebSocket 3. All good!
Figure 6.10 A WebSocket protocol handshake in action as seen in the Network tool of Firefox. The client requests a protocol upgrade that the server accepts. From then on, the client and the server can send each other messages over the TCP connection, which will be kept open until the client or server decides to close it.
171
Beyond REST: the real-time Web of Things
Once the initial handshake takes place, the client and the server will be able to send messages back and forth over the open TCP connection; these messages are not HTTP messages but WebSockets data frames. Text and binary data frames can be sent in either direction and simultaneously. The overhead of each WebSockets data frame is 2 bytes, which is small compared to the 871-byte overhead of an HTTP message meta- data (headers and the like). Add to this the overhead of IP, TCP, and TLS (see chapter 9), and you have an additional 60–100 bytes per message! This makes WebSockets communication a lot less bandwidth-consuming than HTTP.
The syntax and semantics of the messages they exchange are open, but the Sec- WebSocket-Protocol request header can be used to specify a protocol to use inside the data frames (in this example, we use “wot,” which is a fictive sub-protocol). The registered sub-protocols are managed by the Internet Assigned Numbers Authority (IANA).14
WEBSOCKETS FOR THE WOT
What’s really interesting with WebSockets for the Web of Things is that they use stan- dard internet and web technologies. Because they open a TCP connection over port 80, WebSockets aren’t blocked by firewalls and can traverse proxies. Then, because they work in the browser and are bootstrapped via HTTP, they let us use a lot of the principles we looked at when exploring HTTP and REST. First, the hierarchical struc- ture of Things and their resources as URLs can be reused as-is for WebSockets. As you saw in listing 6.14, we can subscribe to events for a Thing’s resource by using its corre- sponding URL and asking for a protocol upgrade to WebSockets. Moreover, Web- Sockets do not dictate the format of messages that are sent back and forth. This means we can happily use JSON and give messages the structure and semantics we’ll work on in chapter 8.
Moreover, because WebSockets consist of an initial handshake followed by basic message framing layered over TCP, they can be directly implemented on many plat- forms supporting TCP/IP—not just web browsers. They can also be used to wrap sev- eral other internet-compatible protocols to make them web-compatible. One example is MQTT, a well-known pub/sub protocol for the IoT that can be inte- grated to the web of browsers via WebSockets. You’ll see that in more detail in the next chapter.
The permanent link created by WebSocket communication is interesting in an Internet of Things context, especially when considering applications wanting to observe—or subscribe to—real-world properties such as environmental sensors. Finally, WebSockets offer all of these benefits with significantly reduced bandwidth consumption when compared to HTTP polling, for example. The drawback, however, is that keeping a TCP connection permanently open can lead to an increase in battery consumption and is harder to scale than HTTP on the server side.
172 CHAPTER 6 Access: Web APIs for Things
6.2.6 The future: from HTTP/1.1 to HTTP/2
When used correctly, HTTP/1.1 is a great protocol to build web services, as you saw in this chapter. But it dates back to 1999. Remember that time? Back then, we were using Windows 95 and using wired phones to call each other, and the IoT term had just been coined! We also mainly used HTTP to display hit counters, sitemaps, and ani- mated “under construction” gifs, but not to display much real-time data and certainly not to interact with devices.
Clearly, the web has evolved tremendously since then, and the need for scalability, performance, real-time messaging, and security has increased significantly. As a result, the internet is about to fully embrace a revolution called IPv6 (see chapter 5) and another called HTTP/2.15 The new protocol wasn’t designed specifically for the IoT,
but the creators of this new protocol clearly took into account some of the needs of the IoT. HTTP/2 focuses on a number of improvements over HTTP/1.1 and can easily run on your Pi!16
PERFORMANCE IMPROVEMENTS
This new version of HTTP allows multiplexing responses—that is, sending responses in parallel. This fixes the head-of-line blocking problem of HTTP/1.x where only one request can be outstanding on a TCP/IP connection at a time17. Furthermore, it fos-
ters clients and servers to use a single TCP connection on which requests and responses are sent in streams.
This is an interesting feature for the WoT because it leads to a more efficient use of connections, which reduces the overhead of HTTP. It also leads to faster transmissions and hence potential savings in terms of battery power required to communicate.18 MORE EFFICIENT FORMATS
HTTP/2 also introduces compressed headers using an efficient and low-memory com- pression format,19 unlike GZIP, the most common compression format used on top
of HTTP. This reduces the size of each HTTP request and response. In addition, whereas HTTP/1.1 was an ASCII protocol—that is, a protocol transmitting ASCII char- acters—HTTP/2 uses binary framing, meaning that it transmits binary streams of data. Binary protocols are more efficient to parse and more compact.
All of this is particularly interesting for the “Web of resource-limited Things” because it means the size of packets is significantly smaller, allowing for devices with limited RAM to happily deal with HTTP/2.
15http://http2.github.io
16There are already several implementations of HTTP/2 for Node.js. Should you want to experiment with HTTP/2 on your Pi, you should try the node-http2module available on https://github.com/molnarg/ node-http2.
17In HTTP/1.1 pipelining was proposed to fix this problem but it did not completely address the problem and is hard to deploy; see https://devcentral.f5.com/articles/http-pipelining-a-security-risk-without-real- performance-benefits.
18Akamai developed a simple page that lets you experiment with these improvements: https://http2.akamai
.com/demo.
173
Summary
SERVER PUSH
Finally, HTTP/2 introduces the notion of server push. Concretely, this means that the server can provide content to clients without having to wait for them to send a request. In the long run, widespread adoption of server push over HTTP/2 might even remove the need for an additional protocol for push like WebSocket or webhooks.
HTTP/2 AND THE WEB OF THINGS
This overview of the features of HTTP/2 and what they mean for the Web of Things is by no means complete, but it shows that the future of the web will make an even better Web of Things. Interestingly enough, you won’t have to change your approach very much: the implementation of HTTP will change, but not the API you build on top of it, because the semantics of HTTP remain unchanged with HTTP/2. Thus, anything you’ll learn in the reminder of this book will be applicable to HTTP/2 as well!
The HTTP/2 specification was officially accepted in February 2015, and several browsers such as Chrome, Firefox, and Opera have started supporting it. This means that the standard is about to be globally deployed and will soon make the Web of Things a lot more efficient!
6.3
Summary
■ When applied correctly, the REST architecture is an excellent substrate on
which to create large-scale and flexible distributed systems.
■ REST APIs are interesting and easily applicable to enable access to data and ser-
vices of physical objects and other devices.
■ Various mechanisms, such as content negotiation and caching of Hypermedia
as the Engine of Application State (HATEOAS), can help in creating great APIs for Things.
■ A five-step design process (integration strategy, resource design, representation
design, interface design, and resource linking) allows anyone to create a mean- ingful REST API for Things based on industry best practices.
■ The latest developments in the real-time web, such as WebSockets, allow creat-
ing highly scalable, distributed, and heterogeneous real-time data processing applications. Devices that speak directly to the web can easily use web-based push messaging to stream their sensor data efficiently.
■ HTTP/2 will bring a number of interesting optimizations for Things, such as
multiplexing and compression.
You’ve had an in-depth look at REST and HTTP, but if you’re hungry for more you might want to have a look at the very good RESTful Web Services by Leonard Richardson and Sam Ruby (O’Reilly Media, 2007)20 or browse to the WoT Publications page,21
where you’ll find a number of resources about using REST for real-world devices.
20http://shop.oreilly.com/product/9780596529260.do 21http://webofthings.org/publications/
174 CHAPTER 6 Access: Web APIs for Things
After being introduced to so much theory about REST, HTTP, and WebSockets, you might be wondering how to actually implement all of this on your Things. Get ready— this is what the next chapter will focus on. You’ll learn how to implement the patterns you’ve learned about in this chapter so that you can access any device, regardless of whether it’s internet-connected or not. Get your coding fingers ready; in the next chapter you’ll need them a lot more!
175