Four TCP-based Communication Protocols That Are Key to IIoT—Part 4: REST API
Content of This Article
Content of This Article
The automation of the future involves IIoT, smart factories, and smart devices. Connectivity is at the heart of this new technological era. Instead of rigid, hierarchical automation pyramids with dividing layers, more extensive network structures are being established in which individual nodes are linked to each other and exchange data.
IIoT-capable devices are needed to implement this type of smart networking. These must be standardized, scalable, IT and OT-capable, and interoperable. They must also be able to communicate securely. Various communication protocols are available for this: MQTT, OPC UA, AMQP, and REST API enable smart communication. In our multi-part series of blog articles, you can find out which properties characterize the respective IIoT communication protocol, and for which use cases it is particularly suitable. The fourth part of the article series is about REST API.
What is REST API and how does it work?
Representation State Transfer (REST) summarizes architectural frameworks that simplify and harmonize communication between devices in a network. It was developed in 2000 by Roy Fielding as part of his Ph.D. thesis. REST can be implemented on the basis of any protocol, but has established itself in Internet networks and is best known for defining architectural frameworks based on the HTTP(S) specification. HTTP is a widely used request/response protocol at the application layer. However, if everybody were to use HTTP on the basis of their own ideas, no synchronization and therefore no communication between the components could take place. REST rectified this situation and harmonized HTTP usage. The core idea behind REST is to transfer the state (from the server) in a representative manner (to the client). There are two important points that should be mentioned here. On the one hand, the server is stateless. No state information is stored about whether and when it was connected to a client. It sends only the instantaneous state to the client and the client can create a state-based application based on the specific states it receives from the server. In addition, the server can send the resources to the client in several representative formats. Each data unit that the client can access in REST is called a resource and is accessible through a unique access point called the Uniform Resource Identifier (URI). Every resource has a URI.
One benefit of REST is that resources are decoupled from their representation. The server can store the resources in any format (in a database, CSV file, or object-based class). However, it can provide the resources in one or more presentation formats such as binary, JSON, XML, YAML, or JPEG. This means that the client accesses the representation, but not the resource itself. Applications and interfaces that use REST are referred to as RESTful.
The following five general conditions must be satisfied for an interface or application to be considered RESTful:
Client/Server
Communication should take place between a client and a server. As mentioned above, the client is the searcher and the server is the supplier of information. For example, in Figure 1, the client asks the server for the temperature, and the server responds with a message containing the temperature in JSON format. Two key components should be included in the client request, namely a URI and an HTTP method. The HTTP methods are actions requested by the client from the server. There are six standard HTTP methods (GET, PUT, POST, DELETE, HEAD, and OPTIONS), which are used in specific situations. For example, GET should be used to receive the state of a resource, PUT to update a resource, POST to create a resource, and DELETE to delete a resource.
Fig. 1: A typical application example for REST API
Statelessness
The server does not remember which client it spoke to. This shifts responsibility for storing the state to the client, making the server more compact to deploy.
Caching capable
The server contains information as to whether its resources are suitable for caching. If this is the case, the resources contain version numbers so that the client receives validity and history information.
Multiple layers
No matter how many layers exist between the client and server, they should be able to communicate with each other, even if there are proxies between them. There may be multiple layers, such as the security layer, the caching layer, and the load-balancing layer, but they should not affect the client and the server’s message transmission.
Uniform interface
Several conditions must be satisfied for a uniform interface:
- Each resource must have a unique identifier in the form of a URI.
- Once the client has a representation of a resource and its metadata (and the appropriate permission), it can add, delete, or modify a resource.
- The exchanged messages should be self-descriptive and contain sufficient information to process the resources.
- Resources are linked together and the client can obtain information about the URIs of all resources by accessing a specific URI.
Interoperability of REST API
The RESTful interface provides multiple standardization capabilities at a syntactic level, such as OpenAPI, RAML, API, and Blueprint. They are standards for describing the RESTful interfaces for humans and computers and enable interaction with each other without ever having to open a manual. This enables the RESTful interface to carry out both machine-machine and human-machine interactions. For machine-machine interaction, both machines can process the REST APIs from their communication partners and access data without human intervention. A human must only interact with the system in the event that a meaningful application must be created (semantic interoperability). In terms of human-machine interaction, several representative tools enable easy understanding and interaction with the REST API.
Real-time behavior of REST API
The RESTful interface, where HTTP is a request/response communication protocol, does not have real-time functionality. The speed of the data update depends on how often the client queries the server. Too many queries can overload the network.
Security of REST API
The RESTful interface does not have its own security mechanisms, since security was not the focus at the time of its development. However, there are many best practices, including user name and password authentication, JWT tokens, and OAuth security mechanisms.
Implementation of REST API compared to MQTT, OPC UA, and AMQP
MQTT and AMQP are designed to be as compact as possible, so there is no room for maneuver and no need for optimization, apart from including or excluding security features. The same applies to the RESTful interface. However, there is some effort required: The RESTful interface is not as simple as MQTT and not as complex as AMQP and OPC UA. An application can be developed very quickly, especially if HTTP is already available as a protocol. From an implementation perspective, the challenge becomes greater when the REST API contains many resources.
Usage of REST API
The RESTful interface has long been a standard in the Internet sector and most users are familiar with it. It is ideal when there is direct communication between two parties that should be easy to understand and use, including for people. There are very few companies that do not have a RESTful interface definition for their own devices or the services they provide. Pepperl+Fuchs also relies on a RESTful API for its sensors. Additionally, REST is very easy to parse in the backend of a website and can be presented in an extremely user-friendly way.
IIoT Communication Protocols Blog Series
White Paper: Four TCP-based Communication Protocols
Learn more about the differences and similarities of the four IIoT communication protocols REST API, MQTT, OPC UA, and AMQP.
Subscribe to our newsletter and receive regular news and interesting facts from the world of automation.