Your Mission: Understand OPC UA, MQTT and REST (Before They Self-Destruct)

A no-nonsense guide to the three protocols every industrial decision-maker should understand.

Jun 28, 2025

You’ve probably heard these terms in every second meeting: OPC UA, MQTT, REST APIs. People toss them around like everyone knows what they mean. But let’s be honest: if you’re not a developer, they all sound the same.

Let’s change that.

Picture This: Mission Impossible

Remember those scenes in Mission Impossible where Ethan Hunt receives a message that self-destructs after 5 seconds? That’s kind of like MQTT: quick, to the point and it only shows up when something important happens.

Now imagine a different scene: someone reads a detailed mission file, asks follow-up questions, gets real-time updates while defusing a bomb and even sends status back. That’s OPC UA: structured, interactive and made for complex operations.

REST? That’s like mailing a postcard to HQ and waiting for a reply. It works, but it’s not built for the heat of the moment.

Why This Matters

Modern factories are full of data: from sensors, machines, controllers, ERP systems, you name it. But data alone doesn’t help. You need the right kind of communication. Think of it like logistics: it’s not just what you ship, but how you ship it.

Choose the wrong protocol and your "data highway" turns into a traffic jam.

A Brief History: Where These Protocols Come From

Understanding the roots of each protocol helps make sense of their strengths:

OPC UA (Open Platform Communications Unified Architecture) started in the 1990s as "OPC Classic," developed by the OPC Foundation (a nonprofit industry consortium). It was originally tied to Microsoft technologies, but evolved into a platform-independent standard (OPC UA) around 2006. Today, it's backed by major industrial players like Siemens, Rockwell, Schneider Electric and is widely used in SCADA and industrial automation.
MQTT (Message Queuing Telemetry Transport) was invented by engineers at IBM and Arcom in 1999. It was designed for minimal bandwidth environments like oil pipelines. Lightweight, simple and now open-standard via OASIS, MQTT is popular in IIoT, with support from a lot of vendors and technologies like HiveMQ, Amazon Web Services and Microsoft Azure.
REST (Representational State Transfer) emerged from academic circles, specifically from Roy Fielding's doctoral dissertation in 2000. It wasn't invented for industry, but for the web. It's now the default standard for APIs, embraced across IT and cloud ecosystems.

All three have active communities:

OPC Foundation provides certifications, events and developer tools.
OASIS MQTT TC steers standardization and publishes enhancements.
REST is decentralized, but supported by countless dev communities like Stack Overflow, GitHub and open-source forums.

Communication Patterns: Request/Response vs. Pub/Sub

Before we go further, it helps to understand the basic types of digital communication:

Request/Response

This is how REST works. One system asks a question, the other answers. Think of it like ordering a coffee: you ask, you wait, you get it. Simple and predictable.

Used in: REST APIs, traditional web communication
Good for: On-demand data, when timing isn’t critical

Publish/Subscribe (Pub/Sub)

This is the model used by MQTT. Devices "publish" messages to a central broker. Other devices "subscribe" to certain message types and get updated automatically.

Industrial Example: A sensor publishes temperature data to a broker. Multiple systems (e.g. dashboard, alert system, cloud storage) subscribe to "temperature" and receive updates without talking to the sensor directly.

Everyday Analogy: Think of a radio station. It "publishes" music. You tune in to the station you like. If the station stops broadcasting, you hear silence, but no one needs to call you to say that. It just happens.

Used in: MQTT, also supported in newer OPC UA setups
Good for: Event-driven data, low bandwidth, decoupled systems

Bidirectional / Client-Server with Subscriptions

OPC UA goes beyond both. It supports client-server requests and subscriptions. That means it can push updates when needed or provide data on request and always with structure and security.

Industrial Example: A SCADA system requests machine status via OPC UA. The machine sends structured data back. If a parameter (like motor temperature) changes significantly, it can push an update immediately without being asked again.

Everyday Analogy: Think of your WhatsApp chat with someone at work. You can send a question (request), get an answer (response), but also get updates without asking ("Hey, quick heads-up: we’re starting now!"). It’s a living conversation, not just one-off requests.

Used in: OPC UA
Good for: Industrial environments with structured, changing data

So How Do These Protocols Actually Work?

Let’s break it down with a metaphor. Imagine three kinds of mail delivery systems:

OPC UA - The Smart Mailman Who Talks Back

OPC UA is like a professional courier who not only delivers your package but can also:

Tell you what’s inside
Notify you if something changes
Speak your local dialect (and 10 others)

He’s well-trained, secure and follows strict delivery rules. This makes him great for complex environments like a production line, where machines need structured, reliable and interactive data exchange.

MQTT - The Doorbell That Only Rings When Something Happens

MQTT works like a wireless doorbell: it only rings when something changes. No unnecessary traffic. That’s why it’s great for sensors and devices that don’t have much bandwidth. MQTT can also use "retained messages". These are like sticky notes on the broker: the last message is kept and delivered immediately to any new subscriber.

REST - The Web Form You Fill Out

REST is like a web form: you ask a system for data and it gives you an answer. Simple, direct and everywhere in IT. But it’s not made for real-time shopfloor communication.

REST works best when you don’t need millisecond updates. Think dashboards, maintenance records, or order systems.

10 Real-World Use Cases and the Right Protocol

Here’s where the rubber meets the road. Ten typical industrial scenarios and the protocol that usually makes the most sense:

Sensor sends temperature every few minutes
→ MQTT: lightweight and event-driven, perfect for periodic updates.
Robot arm sends position data in real-time
→ OPC UA: structured and responsive for precise control data.
Operator logs into HMI panel to check machine status
→ REST: fine for manual queries where timing isn’t critical.
Edge device collects vibration data from multiple motors
→ MQTT: efficient and scalable for many small payloads (payload = the actual data inside the message).
MES system pulls production KPIs hourly
→ REST: scheduled, batch-style access fits the model. (MES = Manufacturing Execution System: controls and monitors the production process in real time)
PLC updates SCADA with alarm status
→ OPC UA: alarms need reliability and structure.
Cloud dashboard displays real-time energy usage
→ MQTT or OPC UA: MQTT if it's aggregated, OPC UA if it's structured and interactive.
Mobile app checks machine runtime history
→ REST: a clear fit for on-demand, read-only access.
Condition monitoring on a legacy CNC machine
→ OPC UA via gateway: brings structure to unstructured data.
Warehouse conveyor sends start/stop events to ERP
→ MQTT: simple events, sent only when needed.

Quick Comparison Table

Real-Life Misstep: When REST Goes Wrong

A mid-sized manufacturer wanted real-time alerts from their packaging line. The integrator used REST because it was familiar. But REST doesn't push updates, it waits for someone to ask.

Result: Alarm data arrived with a delay. Sometimes several seconds late. Not good when you’re tracking jammed machinery.

Lesson: REST is great for on-demand info, not for "something just happened" situations.

Common Pitfalls in Real Projects

Even experienced teams get these wrong:

Using REST for real-time control: REST wasn’t built for millisecond decisions. Don’t rely on it for anything safety-critical.
Ignoring security in MQTT: It’s lightweight, but not secure by default. Add TLS and authentication.
Using OPC UA without certificate management: Great protocol, but setup is complex. Skipping security features can create blind spots.

Ask vendors how they implement these protocols, not just what they use.

Decision Tree: Which Protocol Should I Use?

Use this quick guide to navigate:

Do you need real-time data?
- Yes → OPC UA
- No → Go to 2
Is your data event-driven or infrequent?
- Yes → MQTT
- No → Go to 3
Are you pulling structured reports, metrics or history?
- Yes → REST
- No → Ask again what your goal is.

Vendor Checklist: 5 Questions You Should Ask

What happens if the network connection drops?
Do you support MQTT with retained messages?
Are OPC UA connections secured with certificates?
Are your REST APIs documented with OpenAPI?
Who owns and maintains the broker or server in production?

What Should You Know or Ask?

You don’t need to become a protocol expert. But you should ask:

“Is this protocol right for the environment? Real-time, stable, or lightweight?”
“What happens when the network goes down? Does it retry or fail?”
“Who’s maintaining the communication? IT, OT, or both?”
“Is there a broker, server, or gateway? And where is it hosted?”
“How is the data secured in transit?”

The Big Misunderstanding

Many assume all protocols are interchangeable. They're not. Using REST where you need real-time data is like using email to control a robot arm. Technically possible. Practically risky.

Getting Started (Without Overthinking It)

Ask your integrator why they chose a protocol
Map out where which protocol is used and why
Start with one pilot system and see how it behaves

If You Only Remember Three Things

Use OPC UA for structured, secure and bidirectional shopfloor communication.
Use MQTT for efficient sensor data, especially with limited bandwidth.
Use REST when timing is not critical and clarity is key.

For Advanced Readers: What’s Missing Here (On Purpose)

This post is designed for clarity, not exhaustiveness. If you’re a systems integrator, OT engineer, or protocol nerd, here’s what I simplified:

REST isn’t a protocol, it’s an architectural style. In practice, most people mean HTTP+JSON APIs. I know that. But I chose common language over textbook precision.
MQTT and security: Yes, MQTT can be secure - with TLS, authentication and access control lists (ACLs). But it doesn’t enforce any of that by default, which is why it often gets misused in OT projects.
OPC UA security is nuanced. Just saying “secure by default” glosses over certificate exchange, session handling and role-based access control. It’s powerful and complex.
Pub/Sub exists in OPC UA too. The standard supports it (with UDP and MQTT transports), but it’s still less commonly implemented than classic client-server. I focused on what’s widely used in practice.
Hybrid setups are common. In real factories, you’ll often see REST APIs from cloud platforms, MQTT on the edge and OPC UA in the control layer. Architectures get layered and messy.
Performance isn’t covered here. OPC UA adds overhead. REST has HTTP latency. MQTT is fast, but limited by broker design and QoS settings. A performance comparison would need a lab test or separate whitepaper.

This article is your compass, not your map. Use it to ask better questions and avoid costly detours.

Final Thoughts

Good communication on the shopfloor isn’t just about cables and speed. It’s about choosing the right “mail system” for the job. If you understand the basics, you’ll spot red flags before they become expensive problems.

If you’ve read this far, you’re already ahead of 90% of the room.