1. HTTP—Implementation of RESTful Architecture

When it comes to HTTP, I believe everyone is familiar with it. HTTP stands for Hyper Text Transfer Protocol.

When we normally visit a website http://www.baidu.com/index.html, we are actually using the HTTP protocol to retrieve (GET) the content of the file located at www.baidu.com/index.html on the internet, which is then displayed in the browser:

After the widely used HTTP, there is a clever REST architecture that is relatively unknown.

REST stands for Representational State Transfer, which means the representation layer state transfer in Chinese. REST refers to a set of architectural constraints and principles. If an architecture adheres to the constraints and principles of REST, we call it a RESTful architecture.

REST architecture and HTTP cannot be equated, but currently HTTP is an instance related to REST architecture, so REST is typically described as being implemented through HTTP.

2. Understanding RESTful Architecture

The following understanding of RESTful comes from Ruanyifeng’s blog: Understanding RESTful Architecture^[1].

The term REST was proposed by Roy Thomas Fielding in his doctoral dissertation in 2000. Fielding named his architectural principles for internet software REST, which is an abbreviation for Representational State Transfer. I translate this phrase as “representation layer state transfer”.

If an architecture complies with REST principles, it is referred to as RESTful architecture.

The best way to understand RESTful architecture is to grasp what the term Representational State Transfer means, and what each word signifies. If you understand this name, it won’t be difficult to appreciate what kind of design REST represents.

Resources

The name REST, “representation layer state transfer,” omits the subject. The “representation layer” actually refers to the “representation layer” of the “resources”.

所谓“资源”，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个 URI（统一资源定位符）指向它，每种资源对应一个特定的 URI。要获取这个资源，访问它的 URI 就可以，因此 URI 就成了每一个资源的地址或独一无二的识别符。

What we call “going online” is interacting with a series of “resources” on the internet by invoking their URIs.

Representation

“Resources” are information entities that can have various external representations. The form in which we present “resources” is called their “representation”.

For example, text can be represented in txt format, HTML format, XML format, JSON format, or even in binary format; images can be represented in JPG format or PNG format.

URIs only represent the entity of the resource, not its form. Strictly speaking, some URLs with the suffix “.html” are unnecessary, as this suffix indicates the format, which belongs to the “representation” category, while URIs should only represent the location of the “resource”. Its specific representation should be specified in the HTTP request header using the Accept and Content-Type fields, which are the descriptions of the “representation”.

State Transfer

Accessing a website represents an interaction process between the client and the server. This process inevitably involves changes in data and state.

The HTTP protocol, an internet communication protocol, is a stateless protocol. This means all states are maintained on the server side. Therefore, if the client wants to operate on the server, it must use some means to cause a “state transfer” on the server side. This transfer is built upon the representation layer, hence the term “representation layer state transfer”.

The means used by the client can only be the HTTP protocol. Specifically, there are four verbs in the HTTP protocol that represent operational methods: GET, POST, PUT, DELETE. They correspond to four basic operations: GET is used to retrieve resources, POST is used to create resources (which can also be used to update resources), PUT is used to update resources, and DELETE is used to delete resources.

Summary

In summary, what is RESTful architecture:

(1) Each URI represents a resource;

(2) A certain representation layer of this resource is passed between the client and server;

(3) The client operates on the server-side resources through four HTTP verbs to achieve “representation layer state transfer”.

In one sentence:

URLs are used to locate resources (representations), and HTTP verbs (GET, POST, PUT, DELETE) are used to describe operations on that resource.

3. Implementing REST Architecture in IoT — CoAP

Why implement REST architecture in IoT? The reasons are as follows:

• ① No need to maintain a long connection

In IoT devices, some devices do not need to stay online all the time. Using the MQTT protocol causes a lot of resource waste. For example, smart water meters and smart transport only need to report data at certain intervals, so it is unnecessary to stay online all the time.

• ② Idempotence

Due to the special nature of embedded devices, they often experience disconnections, restarts, and so on, so it is necessary to ensure that the server’s resources remain unchanged regardless of how many times they are operated on (referring to abnormal changes).

• ③ Lightweight

In embedded devices, both storage resources and bandwidth are limited, so the protocol’s data packets must be compact, economical, and efficient.

• ④ Strong Scalability

The data reported by IoT devices and the commands issued may require upgrades after leaving the factory, so the protocol should easily extend or reduce commands. In REST architecture, this can be completely resolved by designing appropriate URIs.

In summary of the above needs, the CoAP protocol was born, which stands for Constrained Application Protocol. The above requirements are precisely the characteristics of CoAP. In the CoAP protocol:

• Using request/response communication mechanism (no long connection maintained);
• Using UDP to transmit data packets (reducing packet length);
• Using URI to uniquely identify cloud resources;
• Using PUT/POST/GET/DELETE methods to operate on cloud resources;

Finally, here’s a vivid example: to report temperature data using the CoAP protocol, the design could be:

The device initiates a request, using the PUT method to upload data 30 to the resource at URI <server address>:5683/data/temperature, indicating the current reported temperature value of 30, and then waits for the server’s response.

References