DEV Community

Cover image for When Should You Use MQTT Instead of HTTP for APIs?
Wanda
Wanda

Posted on • Originally published at apidog.com

When Should You Use MQTT Instead of HTTP for APIs?

#api #architecture #iot #performance

TL;DR

Use MQTT for IoT devices with limited battery, unreliable networks, or pub-sub messaging patterns. Use HTTP for standard web/mobile APIs. MQTT uses 2-byte headers vs HTTP’s 100+ bytes, making it ideal for constrained devices. Modern PetstoreAPI implements MQTT for pet tracking collars and smart feeders.

Try Apidog today

Introduction

Your pet tracking collar needs to send location updates every 5 minutes. It runs on a coin battery that should last 6 months. If you use HTTP, the battery dies in 2 weeks. With MQTT, it lasts the full 6 months.

HTTP is the standard for APIs, but it’s built for browsers, not IoT. MQTT (Message Queuing Telemetry Transport) was designed for constrained devices with low bandwidth and unreliable connections.

Modern PetstoreAPI uses HTTP for web/mobile apps and MQTT for IoT devices: pet tracking collars, smart feeders, and health monitors.

💡 Tip: If you’re building or testing IoT APIs, Apidog supports MQTT alongside HTTP. Test pub-sub patterns, validate message formats, and simulate network failures.

In this guide, you’ll see when MQTT is the better choice over HTTP, with real-world patterns from Modern PetstoreAPI, and practical steps for implementation and testing.

What Is MQTT?

MQTT is a lightweight pub-sub messaging protocol optimized for IoT.

How MQTT Works

Devices publish messages to topics. Other devices subscribe to those topics.

Publisher (Pet Collar):
  Topic: pets/019b4132/location
  Payload: {"lat":37.7749,"lng":-122.4194,"battery":85}

Subscriber (Mobile App):
  Subscribe to: pets/019b4132/location
  Receives: {"lat":37.7749,"lng":-122.4194,"battery":85}
Enter fullscreen mode Exit fullscreen mode

An MQTT Broker routes messages between publishers and subscribers.

Key MQTT Features

  • Tiny headers – MQTT: 2 bytes; HTTP: 100-500 bytes
  • Persistent connections – Connections stay open, reducing handshake overhead
  • Quality of Service (QoS) – QoS 0/1/2 for controllable delivery guarantees
  • Last Will – Broker sends a message if a device disconnects ungracefully
  • Retained messages – Broker stores the last message so new subscribers receive the latest data immediately

MQTT vs HTTP Comparison

Feature MQTT HTTP
Header Size 2 bytes 100-500 bytes
Pattern Pub-Sub Request-Response
Connection Persistent Per-request
Bandwidth Very low Higher
Battery Impact Minimal Significant
Browser Support Via WebSocket Native

Bandwidth Example

Sending 1000 location updates per day:

  • HTTP: 420 KB daily, 12.6 MB monthly
  • MQTT: 52 KB daily, 1.56 MB monthly

MQTT uses 8x less bandwidth.

When MQTT Wins

1. IoT Devices with Limited Battery

Pet tracking collar example:

  • MQTT: 6 months battery life
  • HTTP: 2 weeks battery life

Why: Persistent connection, small headers, less radio time.

2. Unreliable Networks

Cellular devices in spotty coverage:

  • QoS for guaranteed delivery
  • Automatic reconnection
  • Session persistence

3. Many-to-Many Communication

Smart feeder scenario:

Feeder 1 → pets/019b4132/feeding
Feeder 2 → pets/019b4127/feeding
App 1 → subscribes to pets/+/feeding (all pets)
App 2 → subscribes to pets/019b4132/feeding (one pet)
Enter fullscreen mode Exit fullscreen mode

4. Real-Time Sensor Data

Pet health monitor with high-frequency updates:

  • Persistent connection, minimal latency
  • Efficient for rapid, frequent messages

When HTTP Wins

1. Standard Web/Mobile Apps

HTTP is universal:

  • Every language supports HTTP
  • Browsers support it natively
  • Proxies/firewalls easily allow HTTP

2. Request-Response Patterns

Fetching pet details:

GET /pets/019b4132
200 OK
{"name":"Fluffy","species":"CAT"}
Enter fullscreen mode Exit fullscreen mode

HTTP simplifies request-response APIs.

3. Caching Requirements

HTTP supports:

  • Browser caching
  • CDN caching
  • Proxy caching

MQTT has no built-in caching.

4. RESTful APIs

HTTP is ideal for:

  • Status codes (200, 404, 201)
  • Standard methods (GET, POST, PUT, DELETE)
  • Consistent error handling

How Modern PetstoreAPI Uses MQTT

Modern PetstoreAPI Docs – MQTT

Pet Tracking Collars

Collar publishes location:

Topic: pets/019b4132/location
QoS: 1 (at least once)
Payload: {
  "lat": 37.7749,
  "lng": -122.4194,
  "battery": 85,
  "timestamp": "2026-03-13T10:30:00Z"
}
Enter fullscreen mode Exit fullscreen mode

Mobile app subscribes:

const mqtt = require('mqtt');
const client = mqtt.connect('mqtts://mqtt.petstoreapi.com');

client.subscribe('pets/019b4132/location');

client.on('message', (topic, message) => {
  const location = JSON.parse(message);
  updateMap(location.lat, location.lng);
});
Enter fullscreen mode Exit fullscreen mode

Smart Feeders

Feeder subscribes to schedule:

Topic: pets/019b4132/feeding-schedule
Retained: true
Payload: {
  "times": ["08:00", "18:00"],
  "amount": 100
}
Enter fullscreen mode Exit fullscreen mode

Feeder publishes feeding events:

Topic: pets/019b4132/feeding-events
Payload: {
  "timestamp": "2026-03-13T08:00:15Z",
  "amount": 100,
  "dispensed": true
}
Enter fullscreen mode Exit fullscreen mode

Health Monitors

Monitor publishes vitals:

Topic: pets/019b4132/health
QoS: 0 (fire and forget, high frequency)
Payload: {
  "heartRate": 120,
  "temperature": 38.5,
  "activity": "resting"
}
Enter fullscreen mode Exit fullscreen mode

Testing MQTT with Apidog

Apidog supports MQTT alongside HTTP and other protocols.

Test MQTT Pub-Sub

  1. Connect to MQTT broker
  2. Subscribe to topics
  3. Publish test messages
  4. Validate message format
  5. Test QoS levels

Simulate Network Failures

  • Test reconnection logic
  • Verify QoS 1/2 delivery
  • Check Last Will messages
  • Validate session persistence

Compare with HTTP

Test identical scenarios with both protocols:

  • Measure bandwidth usage
  • Compare latency
  • Verify data consistency

Conclusion

MQTT and HTTP serve distinct purposes. Use MQTT for IoT devices with limited resources. Use HTTP for standard web/mobile APIs.

Modern PetstoreAPI demonstrates both in practice: HTTP for user-facing APIs, MQTT for IoT devices. Choose your protocol based on project constraints.

Test both protocols with Apidog to determine the best fit for your use case.

FAQ

Can MQTT work over HTTP?

MQTT can run over WebSocket, which itself works over HTTP. This helps with firewall traversal but sacrifices some MQTT efficiency.

What are MQTT QoS levels?

  • QoS 0: At most once (no acknowledgment)
  • QoS 1: At least once (acknowledged, may duplicate)
  • QoS 2: Exactly once (guaranteed, no duplicates)

Is MQTT secure?

Yes. MQTT supports TLS encryption (MQTTS) and username/password authentication. Modern PetstoreAPI uses MQTTS for all IoT devices.

Can browsers use MQTT?

Yes, via MQTT over WebSocket. Libraries like MQTT.js support browser environments.

How does MQTT compare to WebSocket?

MQTT is an application protocol that can run over WebSocket. WebSocket is just a transport layer; MQTT adds pub-sub, QoS, and IoT-specific features on top of it.

Top comments (0)