When Should You Use MQTT Instead of HTTP for APIs?

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.

Introduction

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

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

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

In this guide, you’ll learn when MQTT beats HTTP, see real examples from Modern PetstoreAPI, and discover how to choose the right protocol for your use case.

What Is MQTT?

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

How MQTT Works

Devices publish messages to topics. Other devices subscribe to 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}

MQTT Broker sits in the middle, routing messages from publishers to subscribers.

Key MQTT Features

1. Tiny headers - MQTT: 2 bytes, HTTP: 100-500 bytes

2. Persistent connections - MQTT keeps connections open

3. Quality of Service (QoS) - QoS 0/1/2 for delivery guarantees

4. Last Will - Message sent if device disconnects unexpectedly

5. Retained messages - Broker stores last message for new subscribers

MQTT vs HTTP Comparison

Bandwidth Example

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:

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

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

2. Unreliable Networks

Cellular IoT devices with spotty coverage:

• QoS for guaranteed delivery
• Automatic reconnection
• Session persistence

3. Many-to-Many Communication

Smart pet 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)

4. Real-Time Sensor Data

Pet health monitor sending updates every second:

• Persistent connection (no overhead)
• Minimal latency
• Efficient for high-frequency updates

When HTTP Wins

1. Standard Web/Mobile Apps

HTTP is universal:

• Every language has HTTP libraries
• Browsers support it natively
• Proxies and firewalls allow it

2. Request-Response Patterns

Getting pet details:

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

HTTP is simpler for request-response.

3. Caching Requirements

HTTP caching works out of the box:

• Browser caching
• CDN caching
• Proxy caching

MQTT has no caching.

4. RESTful APIs

HTTP status codes, methods, and semantics:

• 200 OK, 404 Not Found, 201 Created
• GET, POST, PUT, DELETE
• Standard error handling

How Modern PetstoreAPI Uses MQTT

Modern PetstoreAPI implements MQTT for IoT devices.

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"
}

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);
});

Smart Feeders

Feeder subscribes to schedule:

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

Feeder publishes feeding events:

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

Health Monitors

Monitor publishes vitals:

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

Testing MQTT with Apidog

Apidog supports MQTT testing 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 the same functionality with both protocols:

• Measure bandwidth usage
• Compare latency
• Verify data consistency

Conclusion

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

Modern PetstoreAPI shows how to use both: HTTP for user-facing APIs, MQTT for IoT devices. The right protocol depends on your constraints, not which is “better.”

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

FAQ

Can MQTT work over HTTP?

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

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?

Browsers can use MQTT over WebSocket. Libraries like MQTT.js support browser environments.

How does MQTT compare to WebSocket?

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