原文：https://www.nabto.com/mqtt-vs-rest-iot/

The Internet of Things IoT allows you to automate processes and make things more efficient in any context. However, none of this would be possible if you could not communicate with devices.  In order to do that, a form of language must be established to create a mutual understanding between client and device. That’s where MQTT and REST come in. 

MQTT vs. REST is a debate that rumbles on within the IoT community. They both allow for communication between the devices in your IoT project. However, which one is better?

On the one hand, MQTT is praised for ensuring message reliability, being extremely lightweight and battery friendly. Whereas REST – which is used with HTTP or COAP to implement RESTful IoT services – is easy to use, scalable, and language-independent. 

They both certainly have advantages. However, where do they fall down? And, ultimately, which should you choose for your IoT project? Let’s get into it.

MQTT and REST API: What’s the Difference?

MQTT is a network messaging protocol originally developed by IBM for IoT projects.

It allows communication between devices over TCP/IP and has a “publish-subscribe” model that benefits projects that have devices with low computational power and limited battery.

MQTT requires an “MQTT Broker” for its “publish-subscribe” method. The Broker is software that runs on a computer and acts as a sort of Post Office in which devices can send their data and receive data that they are “subscribed” to.

If you want to learn more about MQTT, check out our blog ‘What is MQTT in IoT and Should you Use It?’

 

Unlike MQTT, REST is actually not a messaging protocol. It is an architectural style for developing web services. REST stands for Representational State Transfer, and given that it’s an architectural style, it can be used with multiple protocols like HTTP or CoAP.

You frequently see MQTT valued for its simplicity, but this can also be a disadvantage. While MQTT mainly sends and receives very simple forms of data, REST API can work with components like files, objects, and media. Furthermore, it can use the POST, DELETE, PUT, and GET methods to use them.

You can learn more about REST by reading our complete guide to REST APIs in IoT.

MQTT: When to Use it?

Now that you know the lingo, let’s get into scenarios where you might use either one of these IoT solutions. First off, MQTT. 

Scenario 1: You’re Using Power-Constrained or Small Devices

The IoT industry is growing, and with that growth comes a wide variety of small and cheap products that can send and receive data with very low processing power. MQTT is ideal in environments where these types of objects are present.

Why? Because the MQTT protocol header is only 2 bytes and because MQTT requires merely a few lines of code to implement. Therefore, the protocol maximizes the amount of energy a battery can use by not sending and receiving unnecessarily large chunks of data. This decreases the frequency in which you have to replace batteries.

Scenario 2: You’re In a Remote Location With Limited Connectivity 

Another benefit of MQTT being lightweight is that, since MQTT messages are small, devices can communicate with each other even with poor internet connection. 

This can be beneficial for IoT projects that are in outdoor environments susceptible to aspects –  like rain – or in places with generally unstable connections. This should come as no surprise. MQTT was specifically developed for the oil and gas industry, so it was designed to work in the desert.

Therefore, if you need message delivery to be reliable no matter where you’re based, MQTT may be a good protocol option.

Scenario 3: You Need to Guarantee Message Delivery

If your IoT project requires the confirmation of a message being delivered, MQTT might be the best solution. Let’s imagine an automated farm as an example. Here, the object tasked with watering the produce can’t do so until the object tasked with monitoring the soil informs it that its time. Otherwise, it would drown the produce.

MQTT has three flags referred to as QOS (Quality of Service) classified as follows:

  • QoS 0: At most once delivery
  • QoS 1: At least once delivery
  • QoS 2: Exactly once delivery

You can apply these flags to any message you think might need it. As a result, you can make sure that important messages are received.

REST: When to Use it?

How about REST? When might you use the most widely used form of API? Let’s take a look.

Scenario 1: It Can Be Used to Integrate with COAP

CoAP is an Internet Protocol for constrained devices that allows communication between them through the internet.

If you have small devices in your IoT project and HTTP+TLS/SSL might be too big of a protocol for them, you can use REST to integrate with CoAP to keep using RESTful programming with small devices. 

You can learn more about CoAP by reading our blog, Websocket vs. MQTT vs. CoAP: Which is the Best Protocol?

Scenario 2: You Need Data Flexibility

Using REST with HTTP or CoAP can allow you to work with components like files, objects, and media on a particular IoT device.

This means that working with REST can allow you to have communication between devices with multiple types of data, instead of being constrained to simple small messages like with MQTT. If you feel that your IoT project has more complicated devices and needs to work with bigger types of data, REST is your best option.

Scenario 3: You are Already Familiar with REST API

If you have ever worked on web development and have experience working with RESTful services, applying REST to an IoT project should be extremely easy to learn for you. Time is valuable in anyone’s life, and if you can take advantage of prior knowledge to apply it to a new context, why wouldn’t you?

Using REST on your IoT project will make it work in a more standard and well understood way, and it will also allow you to use POST, GET, PUT, and DELETE methods with a database system like SQL through CRUD.

This would also be beneficial since already being familiar with the architecture can allow you to make less mistakes, find the causes of errors more quickly, and develop solutions more efficiently.

MQTT vs. REST: How Do They Stack Up in The Areas That Matter Most to IoT Developers?

Now that we’ve looked at times when you might use MQTT or REST, we’re going to take a look at how they stack up in the key areas that matter most to IoT developers.

These include:

  • Latency and responsiveness
  • One-to-many communication
  • Security
  • Privacy
  • Developer Simplicity

Latency and Responsiveness

Independently of the scope of your IoT project, low latency and responsiveness should be a big priority.

Even if you have a relatively small project, you should aim for it to be reliable and not waste your (or anyone else’s) time. MQTT may suffer from high latency for the same reason it’s good for low bandwidth: it’s made for small devices with low processing power.

This means that something like opening a locked door might take a few seconds, if not minutes, or controlling a security camera can be unreliable since the instruction for where to move can be a few seconds behind.

REST on the other hand, does not suffer from high latency because of its client server model. Latency might not be an issue OK for some projects, but it could be a big problem in the industrial or healthcare industry. Overall, REST is the best option for IoT projects where latency and responsiveness is a priority.

Winner: REST

One-to-Many Communication

MQTT offers a publish-subscribe system that makes simultaneous communication between devices extremely easy. MQTT’s Broker can make multiple devices receive data as soon as another device changes state or decides to send data to the Broker.

This makes MQTT ideal for projects where one-to-many communication is necessary. With the publish-subscribe system, you could change the temperature of each room in a house individually when the outside temperature changes, or you could light up every lightbulb when the brightness outside decreases

Therefore, if your IoT project has a lot of devices that need to communicate to each other constantly, automatically, and simultaneously, MQTT can help you achieve this in an easy way.

Winner: MQTT

Security and Privacy

Neither HTTP nor MQTT comes with built-in security.

For HTTP, this can be solved by adding TLS/SSL. However, if that’s too big for your device, Nabto Edge has CoAP+DTLS built-in. This gives REST a clear advantage in overcoming IoT security challenges.

When it comes to privacy, MQTT also falls behind. It doesn’t offer end-to-end encryption. This leaves users’ data vulnerable while passing through the cloud. However, with Nabto Edge, all data is encrypted from end to end and never has to leave the device. As a result, the end-user retains data control and privacy. REST is the clear winner. 

Winner: REST

Developer Simplicity

This category’s result should come as no surprise. As mentioned before, REST is the architecture known from the majority of backend services powering the world wide web.. As a result, it’s extremely simple for developers to pick up and share with one another. 

On the other hand, MQTT requires developers to jump through multiple hoops. It demands:

  • Configuration of a central service
  • A decision to be made on the vendor
  • Regular management and maintenance
  • And an overall hassle.

While some developers do get frustrated by REST’s limited architecture, it remains the most popular API for a reason: simplicity. 

Winner: REST

MQTT vs. REST: The Verdict

We declared REST the winner: REST based solutions are  friendlier to developers, have lower latency, and have better IoT privacy and security. Furthermore, with Nabto Edge, you can make REST an even better API for your IoT device.