MQTT – The messaging protocol MQTT, which stands for Message Queue Telemetry Transport is a publish & subscription based machine-to-machine (M2M) messaging protocol that is designed to be very lightweight but secure. When used in the context of the internet of things, the MQTT message protocol is a great advantage as it supports unreliable bandwidth of internet connection and can handle latency very well. The methods available to the device while communicating with the server are: connect, disconnect, subscribe, unsubscribe and publish.
REST API – The Representational State Transfer (REST) offers interaction by exchanging the textual representation of the resource state by simply using web links (URLs) to identify the resource. The operations available are GET, POST, PUT, PATCH and DELETE that are stateless operations and are always uniform and predeﬁned. The REST protocol is relatively easy to implement, has high performance, is very reliable, supports basic authentication and is therefore an excellent choice to enable communication with the internet of things.
CoAP – The Constrained Application Protocol (CoAP) is also a machine-to-machine transfer protocol and is based on the REST model. CoAP also uses the methods GET, PUT, POST, and DELETE and the resources are also identiﬁed under speciﬁc URLs to eliminate ambiguity. CoAP is also a great ﬁt for the internet of things because this protocol has been developed with a focus on security and therefore uses DTLS parameter that are comparable to a 3072bit RSA key.
gRPC – The General Remote Procedure Call (gRPC) has originally been developed by Google and uses HTTP for the transport of messages and protocol buffers for interface deﬁnition language (IDL). Similarly to other protocols it allows bidirectional communication and basic authentication, however it also enables the client to use remote methods that are deﬁned on the server application.
Weave – Google’s application protocol Weave was originally developed for communication between devices in a local closed network and without external communication to other services such as the cloud. The implementation is based on Thread (ThreadGroup ) and allows a self-healing mesh network that allows devices to work and communicate even is no WiFi is available for a short period of time. Recently, the application protocol Weave has been extended to allow both the local communication and also the communication with the cloud. This protocol has been ﬁrst used for Google’s home automation devices under the name Nest.
WebSocket – is a standardized communication protocol which allows a bidirectionalcommunicationbetweenclientsandaremoteserveroveraTCPconnection when a web application is hosted on a server. To secure the communication for the internet of things, the port 443 is used which provides TLS-encrypted connection. A beneﬁcial property of WebSocket is that that it handles ﬁrewalls and proxies very well which avoids many complications in large network such as when used in the internet of things. WebSocket are relatively efﬁcient for sending small amount of data and is also a good choice for the internet of things.
Z-Wave – is a communication protocol that is similar to Google Weave and primarily focuses on the communication of devices in a closed local network, most often for home automation. The Z-Wave protocol is not only a software but the Z-Wave suite also includes a choice of more than 1500 hardware products that can be easily connected. The open source version of Z-Wave is called OpenZWave and can be extended to add more options to how devices communicate . Although Z-Wave is a very mature and well known framework, it strongly limits the possibilities the developers have and is focusing more on the plug-and-play functionality of devices for non-developers.
ZigBee – is also a communication protocol that can be used to build personal area networks (PANs) for local communication between wireless devices. ZigBee excelsintheverylowenergyconsumptionwhilemaintainingrelativelylargeranges for transmission of data. ZigBee is a great addition to any internet of things project when a local communication is required, however it also lacks the standards for cloud communication which other frameworks provide by default.