A natural question is, why are there any protocols outside of HTTP to transport data across the WAN? HTTP has provided significant services and abilities for the internet for over 20 years, yet was designed and architected for general purpose computing in client/server models. IoT devices can be very constrained, remote, and bandwidth limited. Therefore, more efficient, secure, and scalable protocols are necessary to manage a plethora of devices in various network topologies such as mesh networks.  

In transporting data to the internet, designs are relegated to the TCP/IP foundation layers. TCP and UDP protocols are the obvious and only choice in data communication with TCP being significantly more complex in its implementation than UDP (being a multicast protocol). UDP, however, does not have the stability and reliability of TCP, forcing some designs to compensate by adding resiliency in the application layers above UDP. 

Many of the protocols listed in this chapter are Message Orientated Middleware (MOM) implementations. The basic idea of a MOM is that communication between two devices takes places using distributed message queues. A MOM delivers messages from one user-space application to another. Some devices produce data to be added to a queue while others consume data stored in a queue. Some implementations require a broker or middleman be the central service. In that case, producers and consumers have a publish and subscribe-type relationship with the broker. AMQP, MQTT, and STOMP are MOM implementations; others include CORBA and Java messaging services. A MOM implementation using queues can use them for resilience in design. Data can persist in the queues, even if the server fails. 

The alternative to MOM implementation is RESTful. In a RESTful model, a server owns the state of a resource but the state is not transferred in a message to the server from the client. RESTful designs use HTTP methods such as GET, PUT, POST, and DELETE to place requests upon a resource's Universal Resource Identifier (URI) (see the following figure). No broker or middle agent is needed in this architecture. As they are based on the HTTP stack, they enjoy the majority of services offered, such as HTTPS security. RESTful designs are typical of client-server architectures. Clients initiate access to resources through synchronous request-response patterns.

Additionally, clients are responsible for errors, even if the server fails. The figure below illustrates a MOM versus a RESTful service. On the left is a messaging service (based on MQTT) using a middle broker server and publishers and subscribers to an event. Here many clients can be both publishers and subscribers and information may or may not be stored in queues for resiliency. On the right is a RESTful design where the architecture is built upon HTTP and uses HTTP paradigms for communicating from the client to the server: