3 Engineering IoT Networks
149
in such a way as to be idempotent, which also helps prevent adverse outcomes
from collisions between two PATCH requests on the same resource in a similar
time frame. Collisions from multiple PATCH requests may be more dangerous
than PUT collisions because some patch formats need to operate from a known
base-point, or else they will corrupt the resource. Clients using this kind of patch
application should use a conditional request such that the request will fail if
the resource has been updated since the client last accessed the resource. For
example, the client can use a strong ETag in an If-Match header on the PATCH
request.
• DELETE method. It is used to delete a resource identified by a URI. On
successful deletion, it returns HTTP status 200 (OK) along with a response body,
e.g., the representation of the deleted item or a wrapped response. DELETE
operation is idempotent regarding the deleted resource but not regarding the
return code. Calling DELETE on a resource a second time will often return 404
(NOT FOUND) since it was already removed and therefore is no longer available.
This, by some opinions, makes DELETE operations no longer idempotent;
however, the end-state of the resource is the same. Returning a 404 is acceptable
and communicates the status of the call accurately.
3.4.4 Message Queuing Telemetry Transport (MQTT)
Message Queuing Telemetry Transport (MQTT) is an ISO standard (ISO/IEC PRF
20922) describing a publish/subscribe messaging protocol [80, 81]. It works on top
of the TCP/IP Protocol even if MQTT-SN is a variation of the main protocol aimed
at embedded devices on non-TCP/IP networks, such as ZigBee.
3.4.4.1 How MQTT Works
An MQTT session starts with a client creating a TCP/IP connection with the broker
by using either a standard port or a custom port defined by the broker’s operators.
An MQTT connection is established by using the following standard ports: 1883
for non-encrypted communication and 8883 for encrypted communication using
SSL/TLS. The client validates the server certificate to authenticate the server during
the SSL/TLS handshake. The client may also provide a client certificate to the
broker during the handshake, which the broker can use to authenticate the client.
Whilst not part of the MQTT specification, it has become customary for brokers to
support client authentication with SSL/TLS client-side certificates. This protocol is
designed to be low-demanding in terms of resources especially for IoT applications.
As a consequence, relying on SSL/TLS might not be an optimal solution. In these
cases, authentication is done by sending non-encrypted username and password as
part of the CONNECT/CONNACK packet sequence. This is the case with public
149
in such a way as to be idempotent, which also helps prevent adverse outcomes
from collisions between two PATCH requests on the same resource in a similar
time frame. Collisions from multiple PATCH requests may be more dangerous
than PUT collisions because some patch formats need to operate from a known
base-point, or else they will corrupt the resource. Clients using this kind of patch
application should use a conditional request such that the request will fail if
the resource has been updated since the client last accessed the resource. For
example, the client can use a strong ETag in an If-Match header on the PATCH
request.
• DELETE method. It is used to delete a resource identified by a URI. On
successful deletion, it returns HTTP status 200 (OK) along with a response body,
e.g., the representation of the deleted item or a wrapped response. DELETE
operation is idempotent regarding the deleted resource but not regarding the
return code. Calling DELETE on a resource a second time will often return 404
(NOT FOUND) since it was already removed and therefore is no longer available.
This, by some opinions, makes DELETE operations no longer idempotent;
however, the end-state of the resource is the same. Returning a 404 is acceptable
and communicates the status of the call accurately.
3.4.4 Message Queuing Telemetry Transport (MQTT)
Message Queuing Telemetry Transport (MQTT) is an ISO standard (ISO/IEC PRF
20922) describing a publish/subscribe messaging protocol [80, 81]. It works on top
of the TCP/IP Protocol even if MQTT-SN is a variation of the main protocol aimed
at embedded devices on non-TCP/IP networks, such as ZigBee.
3.4.4.1 How MQTT Works
An MQTT session starts with a client creating a TCP/IP connection with the broker
by using either a standard port or a custom port defined by the broker’s operators.
An MQTT connection is established by using the following standard ports: 1883
for non-encrypted communication and 8883 for encrypted communication using
SSL/TLS. The client validates the server certificate to authenticate the server during
the SSL/TLS handshake. The client may also provide a client certificate to the
broker during the handshake, which the broker can use to authenticate the client.
Whilst not part of the MQTT specification, it has become customary for brokers to
support client authentication with SSL/TLS client-side certificates. This protocol is
designed to be low-demanding in terms of resources especially for IoT applications.
As a consequence, relying on SSL/TLS might not be an optimal solution. In these
cases, authentication is done by sending non-encrypted username and password as
part of the CONNECT/CONNACK packet sequence. This is the case with public