When a PLC must exchange data with an IT system, two common choices are REST API and MQTT. They are not competing versions of the same protocol. They represent different communication patterns.
REST and MQTT at a glance
| Question | REST API | MQTT |
|---|---|---|
| Communication style | Request and response | Publish and subscribe |
| Main connection | Direct HTTP endpoint | Broker |
| Good for | Commands, queries, transactions | Telemetry, events, many consumers |
| Data direction | Usually explicit | Decoupled from publisher and subscriber |
| Key design issue | Timeout and retry | Topic, QoS, retained message policy |
The correct choice depends on the business action, not on the fact that the system is called IIoT.
REST for explicit actions
REST is useful when the controller needs to request or submit a specific resource.
CODESYS Controller ── HTTP POST ──> Web Service
<─ HTTP Response ─
Examples include sending a completed batch record, requesting a recipe, or updating a maintenance status. The application must handle HTTP status codes, timeouts, invalid payloads, and retries.
A retry policy should avoid sending the same business action repeatedly without understanding whether the first request succeeded. Idempotency keys or unique transaction IDs can help the server recognize duplicates.
MQTT for telemetry and events
MQTT uses a broker to decouple the publisher from subscribers.
PLC ── publish ──> MQTT Broker ──> Dashboard
└──> Historian
└──> Alert Service
This pattern is useful when the same temperature, energy, or status data must be consumed by several systems. The PLC does not need a separate direct connection to each consumer.
Topic design matters
A topic should describe stable meaning and location. For example:
site/plant-a/line-01/panel-a/temperature
site/plant-a/line-01/panel-a/status
site/plant-a/line-01/panel-a/alarm
Do not encode rapidly changing values into topic names. Put values, timestamps, quality, and units into the payload.
{
"value": 42.8,
"unit": "degC",
"quality": "good",
"timestamp": "2026-08-11T01:00:00Z"
}
QoS is a business decision
MQTT QoS levels should match the consequence of message loss and duplication. A high QoS level does not automatically make an application safe. The receiving application still needs validation, timestamps, duplicate handling, and stale-data detection.
Telemetry may tolerate an occasional missed value when the next sample arrives soon. A production event or alarm may require stronger delivery and explicit acknowledgement at the application level.
A practical decision rule
Use REST when the requirement sounds like:
“Ask that system for something” or “submit this transaction.”
Use MQTT when the requirement sounds like:
“Publish this state so any approved system can consume it.”
Many real systems use both: MQTT for continuous telemetry and REST for configuration, commands, or transactional records.
Conclusion
REST and MQTT solve different problems. A well-designed CODESYS IIoT solution selects the protocol per data flow, defines error behavior, and keeps payloads meaningful. Protocol choice should follow operational behavior and ownership—not fashion.
The final article connects these patterns into a PLC–Edge–Cloud reference architecture with practical security and commissioning checks.