REST – It’s Not Like All The Rest!

If you’re an expert on Modbus TCP, EtherNet/IP, PROFINET IO or OPC UA, you’re going to be confounded by REpresentational State Transfer (REST). REST is not a protocol and not a technology but an architectural concept for moving data around the Internet. The REST architecture or a RESTful interface is simply a very flexible design, usually built on top of HTTP, for Client devices to make requests of Server devices using well-defined and simple processes.

What makes REST so significant is its widespread acceptance for many important applications as a simpler alternative to SOAP (Simple Object Access Protocol) and WSDL (Web Services Description Language). Leading companies like Yahoo, Google, and Facebook have passed beyond SOAP and WSDL-based interfaces in favor of this easier-to-use, resource-oriented model to expose their services.

Not many people are aware that every time they browse a web page, they are using the REST architecture.

What is REST?

In REST, the concept of how devices on a network function are different than the conceptual view of a network for most other networking technologies. We usually think of a network as a set of devices that provide some specific set of services. A Modbus device, for example, provides a specific set of services like Read Coil, Read Holding Register, Write Coil, Write Register Single. EtherNet/IP Adapter devices and other CIP (Common Industrial Protocol) devices provide services like Read Attribute and Write Attribute. In most technologies used in Industrial Automation, there is some set of predefined services that Client devices must learn, implement, and use to access the resources of a device.

This architecture works well in tightly controlled systems that serve smaller problem domains. For many years, Modbus was the accepted way to pull data out of energy meters. Read Register was the command to get values from energy meters. In well-defined paradigms like energy data collection, these kinds of architectures make sense.

In these systems, it was just accepted that if a Server device like an energy meter implemented a new service like the capability to track detailed energy usage over a small period of time in great detail, all the Clients that wanted access to that new resource would be adapted with new software to use that feature.

That sort of architecture works well in these limited paradigm systems, but it doesn’t work well in the world of the World Wide Web. There, we have a case of unlimited, ever-changing resources being made available in vast amounts.

It would be massively impractical to update our web browsers every time a change was made to a web page. The reason we don’t do that is that the interaction between your web browser and the web Server is an example of a RESTful interface. Your web browser does an HTTP GET which retrieves markup text containing text and hyperlinks to other web pages. You now know more about the resources offered by that Server and can request more information by clicking on one of the hyperlinks. That click repeats the process, another HTTP Get is issued, a new set of markup text is delivered, and you have access to more pertinent resources.

This works because a different mindset is in place about servers and the resources they offer. This mindset is resource-centric instead of function-centric. In the RESTful architecture, a Server is viewed as a set of resources, nouns if you will, that can be operated on by a simple set of verbs like GET, POST, UPDATE, and the like. This architecture yields a much more flexible mechanism for retrieving resources than the limited function-centric kinds of technologies we’ve used in the past.

There are just a few principles that define REST:

REST is an architecture style—all web interactions can be said to be REST architecture operations.

REST is not a standard—there is no specification for it from some standards body.

REST is a stateless Client-Server protocol. Stateless meaning that the Server remembers nothing from any previous interaction with that Client.

REST is based on HTTP but there is no reason it can’t be implemented on any other transport.

RESTful applications use the simple HTTP services called CRUD (Create/Read/Update/Delete).

Like other Web Services, REST has no built-in security, it offers no encryption, doesn’t do session management or any other added-value service. These can be made available by adding components to the transport or by using different transport like HTTPS.

How is REST used?

Yahoo and Facebook have created RESTful Client APIs which simplify the process of accessing resources within their systems. These APIs have largely replaced the remote procedure call technologies previously used, like SOAP and WSDL. In fact, it’s clear that all these types of remote procedure call technologies are obsolescing and taking their place in Internet history.

But you might say, it’s clear that the REST architecture is perfect for browsers and humans accessing web pages but how is it used for machine to machine (M2M) kinds of communication?

That’s one of the reasons that HTTP is so perfect for a REST architecture. REST has a built-in feature that allows the Client to select the format in which the Server should return the resource. Web browser Clients use the resource to return markup language (HTML) that can be displayed. Machines, on the other hand, can request things like Java objects, XML, CSV files, and other data more easily processed by machines.

Summary

REST is a very good alternative for building simple IoT applications. It is simple to understand, easy to implement, but less functional than some of the other alternatives. As a simple mechanism to move factory floor data to an IT application or cloud Server, REST can be a good choice. You can implement a factory floor Server that provides a REST interface, and define Java objects, XML, or CSV as the delivery format for your data. It won’t be real-time—but you don’t always need real-time data.