I Dream of IoT/Chapter 3 : IoT and Web Services

Introduction to web services

Web services are distributed application components that are extremely available. We can use them to integrate computer applications that are written in different languages and run on different platforms. Web services such as HTTP are language- and platform-independent because vendors have agreed on common web service standards. HTTP web services exchange data with remote servers using nothing but the operations of HTTP. If you want to get data from a server, use HTTP GET, send new data to the server, and use HTTP POST and some other functions. That’s it: no registries, no envelopes, no wrappers, and no tunneling. The "verbs" built into the HTTP protocol are mapped directly to application-level operations for retrieving, creating data etc.

How to access web services

SOAP stands for Simple Object Access Protocol, a standards-based web services access protocol. SOAP offers long-term benefits and has been around for a while. Developed by Microsoft, SOAP uses XML to provide messaging services, though making requests and receiving responses in SOAP can become extremely complex. Like other programming languages, the XML of SOAP is intolerant of errors. However, one of the most important features of SOAP is its built-in error handling; if there’s a problem with the request, a response with information about the error is sent.

REST stands for Representational State Transfer which contains a set of stateless architectural principles. REST can manage web services that focus on a system's resources as well as how resource states are addressed and transferred over HTTP by a wide range of clients written in different languages. REST acts as light-weight alternative and uses a simple URL in many cases instead of XML for requests. REST permits many different data formats, which by outward appearances adds complexity. However, due to support for JSON, this allows REST to better support browser clients as JSON is usually a better fit for data and parses much faster.

Comparison

SOAP:

• Is language-, platform-, and transport-independent
• Proves efficient in distributed enterprise environments
• Is standardized
• Provides significant pre-build extensibility in the form of the WS* standards
• Offers built-in error handling
• Allows for automated tasks

REST:

• Uses smaller message formats
• Runs quickly because no extensive processing required
• Looks similar to other web technologies in design philosophy
• Proves low-cost in how it interacts with the web service
• Offers a smaller learning curve

Which one is better for the Internet of Things?

Both SOAP and REST are suitable for the Internet of Things (IoT). REST is better suited for IoT applications involving mobile and embedded devices, while SOAP adheres better to the requirements of business applications. This is because REST represents the most straightforward and simple way of achieving a global network of smart things, while SOAP has strong security requirements.

HTTP protocols

Existing HTTP/1.1

HTTP/1.1 makes information flow faster by providing a persistent connection that allows multiple requests to be batched or pipelined to an output buffer. When a browser supporting HTTP/1.1 indicates it can decompress HTML files, a server will compress them for transport across the internet, providing a substantial aggregate savings in the amount of data that has to be transmitted. Besides that, HTTP/1.1 also provides the ability to have multiple domain names share the same internet address (IP address). This simplifies processing for web servers that host a number of web sites in a practice that is sometimes called virtual hosting.

HTTP/2, the next generation

The main advancements to come out of HTTP/2 are:

1. Multiple streams in single HTTP connection (multiplexing): Streams are similar to data channels. A single established data connection from a client to the server have a multiple streams inside it. This means various streams can exchange data between the server and the client at the same connection unit. Whether by client or server, or shared stream, both parties can exchange data at the same time, and streams can be disconnected or closed either by client or server.
2. Setting priority in a request: Data requested by the client that has extra urgency can be set with a priority flag, which is processed by the receiving end. The stream identifier, which declares priority for the streams, is also set with the help of a 31-bit priority identifier. The value of 0 means a high-priority stream.

HTTP evolution

HTTP/1: Rapid Growth and Informational RFC

A rapid co-evolution of the HTML specification occurred between 1991 and 1995, and the web browser grew as a new breed of software with quick growth for the consumer-oriented public internet infrastructure. A growing list of desired capabilities of the nascent web and their use cases on the public web quickly exposed many of the fundamental limitations of HTTP/0.9. A new protocol was required, one that could serve more than just hypertext documents: it needed to support richer metadata about the request and the response, enable content negotiation and more. In return, the nascent community of web developers responded by producing a large number of experimental HTTP server and client implementations through an ad hoc process, ones that could be implemented, deployed, and potentially adopted by others.

HTTP/1.1: Internet Standard

The HTTP/1.1 standard resolved a lot of the protocol ambiguities found in earlier versions and introduced a number of critical performance optimizations. The most obvious difference: it allowed for two object requests, one for an HTML page and one for an image, both delivered over a single connection. This connection could be kept alive, allowing for the reuse the existing TCP connection for multiple requests to the same host and delivering a much faster end-user experience. In order to terminate the persistent connection, the second client request could send an explicit close token to the server via the connection header. Similarly, the server could notify the client of the intent to close the current TCP connection once the response was transferred. Technically, either side could terminate the TCP connection without such signal at any point, but clients and servers were to provide it whenever possible to enable better connection reuse strategies on both sides.

HTTP/2: Improving Transport Performance

In order to overcome new challenges, the HTTP protocol has had to evolve. In 2012, the HTTP working group announced work on the new HTTP/2.0 protocol, with the specification getting published in May 2015. The primary focus of HTTP/2 has been on improving transport performance and enabling both lower latency and higher throughput. It is crucial to remember that none of the high-level protocol semantics are affected, which means all HTTP headers, values and use cases are the same. Any existing website or application can and will be delivered over HTTP/2 without modification. The HTTP servers will have to speak HTTP/2, but that should be a transparent upgrade for the majority of users. If the working group proves to have met their goal, the single difference should be that our applications are delivered with lower latency and better utilization of the network link.

HTML5 for IoT

HTML 4.x overview

HTML 4.x was the first version to include cascading style sheets as part of the HTML standard. To achieve the transition, the W3C provided three versions of HTML 4: transitional, frameset and strict. While it continues to serve as a rough guide to many of the core features of HTML, it does not provide enough information to build implementations that interoperate with each other and, more importantly, with web content. Additionally, HTML 4 extended HTML with mechanisms for style sheets, scripting, frames, and embedded objects, and it improved support for right-to-left and mixed-direction text, rich tables, and forms while also offering improved accessibility for people with disabilities.

HTML5 with WebSocket for IoT

WebSockets provide a new protocol between client and server that runs over a persistent TCP connection. Bi-directional and full-duplex messages can be sent between the single TCP socket connection (simultaneously or back and forth) through a TCP connection. This is because it is an independent TCP-based protocol and doesn’t ideally require HTTP tunneling, allowing for simplified communication when sending messages.

Is HTML5 with WebSocket more suitable for IoT? It tends to be as WebSockets are better for situations that involve low-latency communication, especially for client-to-server messages. For server-to-client data you can get fairly low latency using long-held connections and chunked transfer. However, this doesn't help with client-to-server latency, which requires a new connection to be established for each client to server message.

Semantic web services

Semantic web services, just like other conventional web services, are on the server end of a client–server system for machine-to-machine interaction through the World Wide Web. In a May 2001 issue if Scientific American, Berners-Lee et al. described it as such: "The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation." It is the advance form of the current web, where all the contents have well defined meanings (easy information interpretation) and it enables the automated processing of web contents by machines (machine-accessible). In semantic web services composition, machines can automatically select, integrate and invoke various web services in order to achieve the user-specified task according to the user constraints. The web performs more work than the user because it involves both routine and complex tasks to be performed on the web without user involvement, hence saving time for composing and integrating information. The machine-processable semantics are added to data, and with the help of well-defined semantics, machines can understand the information and process it on behalf of the human user, whereas web services aim at global infrastructure for distributed computation.

Ontology Web Language (OWL)

OWL is a high-level language (XML-based) used to describe the web services' properties. It consists of three parts: service profile, process model and grounding. The service profile includes general information and is used to describe what the service will do. The process model describes how the service will perform its functionally, while grounding describes links with industry standards. Its main goal is to enable users to automatically discover, invoke, compose and execute web services under certain conditions.

Web Service Modeling Ontology (WSMO)

WSMO is used for describing the semantics of web services. It consists of four parts: goals, ontologies, mediators and web services. The goal defines the user's desires. Ontologies define formal semantics for the terms describing data to achieve interoperability among other WSMO elements. The mediator is used to handle interoperability problems between different WSMO elements, while web services describe the functional behavior, precondition, post condition, control flow etc. of an existing deployed service.

Conclusion

Web services is one of the key elements of the so-called programmable web. They can be effectively used to participate in and set up business-to-business transaction and are great at exposing software functionally to the user while integrating heterogeneous platforms. Web services are based on open and commonly accepted internet protocols. They are not good in everything but certainly represent a category of software agents that we are all looking for.