3.1.4 "HTTPS/REST"

Even if you are unfamiliar with IT and OT, you will most likely already have heard of HTTP, HTTPS or REST. These protocols are leveraged every time you open a website and are a classic example of client-server architecture.

In this article we will explain these protocols in detail, going over what they can do and why they are implemented.

HTTP / Hypertext Transfer Protocol

HTTP is an application layer server/client protocol, which allows for web based apps to exchange data in a consistent manner.

It is based on a request-response cycle. A client makes a request by sending a message to the server, which then formulates a response and sends it back. For example if the client wants to access a site like “www.example.com/example/example.html", it would send a request with a GET method (more about that later) and if the client has access rights to the content, the server will send the contents of the html page back.

An important feature is that it is stateless, meaning that messages are interpreted independent of each other. This allows for clients to make multiple requests without later requests being influenced by the previous ones and that all responses can be interpreted independent of another.

With this protocol it is very convenient and reliable to move all sorts of data types through the web. Not only html files, but videos or other data formats.

HTTP Request messages are built in a uniform way.

First comes the start line, which contains a METHOD, a URI and the HTTP version the client wants to communicate in.

Afterwards come the headers, which are key:value pairs. Some example would be declaring the host, the accepted response files, the accepted languages and so on.

The Method is basically what the client would want the server to do. A couple of examples are:

• GET, to retrieve the content of the URI address
• POST to submit content to the URI address
• DELETE to delete the content of the URI address
• CONNECT to establish a connection to the specified content

There are also a couple of others, but we are just covering those at this point.

The next part is the URI. This is short for Unique Resource Identifier and is basically the relative path of the resource requested on the host site. For the example above it would be “/example/example.html”

The Response message is built somewhat similarly. It contains the HTTP version it is responding in the header as well as a response code. You might be familiar with a couple of those already. For example a 200 code means a successful response, where are 300 means multiple responses available, 400 means the request had incorrect syntax and 500 means there was an issue internally with the server. There are a lot more response codes so if you want to look them up, here would be a source for that.

For a summary of this information we recommend the following videos:

HTTPS / Hypertext Transfer Protocol Secure

HTTPS is basically HTTP with an added asymmetric encryption via TLS (Transport Layer Security). It keeps the data safe by
a clever combination of asymmetric encryption and hash functions. Please watch the following video if you want to know all about the details of how TLS secures the connection during communication.

REST API / Representational State Transfer

REST is not a protocol, but a paradigm, which allows for standardization of IoT communication. Please do note that the HTTP protocol is REST compliant (also called RESTful) for the most part.

It constrains machine-to-machine communication, like through HTTP protocol. REST is widely accepted throughout the software industry and is used as guidelines to create and maintain reliable web APIs. Because of this it is nowadays standard for web based applications with client-server architecture.

The specific constraints are detailed below:

• Clients are defined as requesting resources, while Servers are responding to the requests accordingly. Generally devices can fulfill both roles but during a single request cycle a device can only be either or.
• RESTful architecture is stateless and therefore each request is independent of each other
• Response messages are labeled as cacheable or non-cacheable
• The Interface between client and server is uniform. For example a Windows PC must be able to access the REST Endpoint in the same way as an iPhone.
• RESTful architecture may be layered, but the client does not require to know the implementation to receive a response
• (optional) Servers may be able to send code to the client for execution if required

If you would like to know more you can watch the following video: