REST API vs MQTT: Kapan Pakai Yang Mana di Proyek IoT ESP32

Pendahuluan — Dua Cara ESP32 Berbicara ke Dunia

Di Seri 1, kamu sudah membangun web server ESP32 dengan endpoint /api/data (artikel #6) — klien meminta data lewat HTTP. Lalu di artikel #7, ESP32 mendorong data sensor ke broker MQTT begitu ada pembacaan baru.

Keduanya valid. Masalahnya: tutorial IoT sering memaksa satu protokol untuk semua kasus. Artikel Jalur B ini menjawab pertanyaan praktis: kapan REST API (HTTP), kapan MQTT, dan kapan kombinasi keduanya — sebelum kamu lanjut ke pipeline data (#18, #19) atau smart home (#21–#23).

Prasyarat: Sudah baca web server ESP32 (#6) dan MQTT dasar (#7). Disarankan paham broker pribadi (#16) dan dashboard capstone (#10).

Pull vs Push — Intuisi Dasar

REST API di ESP32 — Kapan Pakai?

Pilih HTTP REST jika:

• Hanya satu atau sedikit klien yang sesekali cek suhu (browser di LAN, Postman, script cron)
• Kamu butuh respons langsung dalam satu request tanpa infrastruktur broker
• Prototipe cepat — buka IP ESP32, lihat JSON, selesai (pola #6)
• Perangkat tidak perlu online 24/7; ESP32 boleh tidur (deep sleep #11) lalu bangun, serve HTTP, tidur lagi

Kelemahan REST untuk IoT skala: setiap klien harus polling — boros bandwidth dan baterai jika interval pendek. Sepuluh dashboard yang polling tiap 1 detik = sepuluh kali beban WiFi yang sama.

// Pola ringkas dari artikel #6 — handler REST
void handleAPI() {
  float suhu = dht.readTemperature();
  float rh = dht.readHumidity();
  String json = "{\"suhu\":" + String(suhu) + ",\"kelembaban\":" + String(rh) + "}";
  server.send(200, "application/json", json);
}

Akses dari laptop: GET http://192.168.1.100/api/data — tidak perlu broker Mosquitto.

MQTT — Kapan Pakai?

Pilih MQTT jika:

• Banyak subscriber butuh data yang sama: Grafana (#19), Node-RED (#23), Home Assistant (#21), subscriber Python (#18)
• Data harus push real-time — relay, alert, grafik live tanpa refresh manual
• ESP32 di lapangan dengan koneksi tidak stabil — QoS & LWT (#17) menjaga reliabilitas
• Arsitektur decoupled: sensor tidak perlu tahu siapa yang consume data

// Pola ringkas dari artikel #7 — publish MQTT
const char* topic = "kodingindonesia/esp32/dht22/data";
// Payload dengan timestamp (#34):
// {"suhu":28.5,"kelembaban":65.2,"timestamp":"2026-07-02T14:30:00","unix":1782977400}
mqttClient.publish(topic, json.c_str());

Broker contoh: 192.168.1.50:1883, user kindo_esp32 / placeholder GANTI_PASSWORD_MQTT — detail di #16.

Perbandingan Lengkap REST vs MQTT

Arsitektur Hybrid — Best of Both Worlds

Proyek produksi sering memakai keduanya:

  [ ESP32 ]
     |-- MQTT publish --> [ Mosquitto #16 ] --> Grafana / Python / HA
     |
     +-- HTTP GET /api/data --> [ Browser lokal / debug ]

  Atau:

  [ ESP32 ] --MQTT--> [ Broker ] --> [ Backend REST API ]
                                           |
                                           +-- GET /api/v1/sensor (untuk app mobile)

Sensor tetap push via MQTT; aplikasi mobile atau partner eksternal baca lewat REST API di server (bukan langsung ke ESP32). Ini pola yang dipakai Grafana (#19) dan MySQL (#18): ESP32 tidak expose HTTP ke internet.

Pro tip: Jangan expose /api/data ESP32 langsung ke internet. Letakkan reverse proxy + auth di VPS, atau arahkan semua konsumsi eksternal lewat backend yang sudah subscribe MQTT.

Contoh Skenario Keputusan

1. Greenhouse kecil, 1 orang pantau HP di WiFi rumah → REST (#6) cukup; refresh manual atau auto-refresh JS.
2. 5 sensor + Grafana + alert Telegram → MQTT (#7) + stack #18/#19.
3. Smart home + automasi PIR → MQTT wajib (#24, #21).
4. Node baterai solar, kirim tiap 15 menit → MQTT publish lalu deep sleep; hindari HTTP server always-on.
5. Integrasi API partner (mobile app) → MQTT ke backend internal; partner pakai REST API server kamu.

Payload & Format Data — Samakan Keduanya

Agar migrasi REST → MQTT mudah, pakai JSON yang sama di kedua protokol:

{"suhu":28.5,"kelembaban":65.2,"timestamp":"2026-07-02T14:30:00","unix":1782977400}

Field unix dari NTP (#34) membuat data REST dan MQTT bisa masuk ke tabel sensor_readings (#18) atau InfluxDB (#19) tanpa transformasi berbeda.

Keamanan: HTTP vs MQTT di Produksi

• LAN saja: HTTP port 80 dan MQTT 1883 plain — OK untuk lab (bukan password hardcode di firmware)
• Internet: HTTPS (reverse proxy) untuk REST; MQTT over TLS (#17) port 8883 untuk ESP32 → broker
• Jangan pakai test.mosquitto.org untuk data produksi — gunakan broker pribadi (#16)
• REST: validasi input pada POST/PUT; MQTT: ACL user terpisah publisher vs subscriber (#18)

Integrasi dengan Pipeline Data Seri 2

Setelah memilih MQTT sebagai tulang punggung sensor:

• Subscriber Python → MySQL (#18) — arsip SQL
• InfluxDB + Grafana (#19) — grafik histori
• Node-RED (#23) — otomasi tanpa ubah firmware

REST tetap berguna untuk panel debug lokal di ESP32 atau endpoint OTA status — tidak menggantikan MQTT untuk multi-consumer.

Checklist: Pilih Protokol dalam 2 Menit

1. Lebih dari 2 konsumen data? → MQTT
2. Butuh grafik/DB histori? → MQTT (+ #18/#19)
3. Hanya buka browser sesekali di LAN? → REST (#6)
4. Node baterai deep sleep? → MQTT publish lalu tidur (bukan HTTP server 24 jam)
5. Partner butuh API standar? → Backend REST yang consume MQTT internal
6. Ragu? → Mulai MQTT (#7) + broker (#16) — skala lebih mudah nanti

HTTP POST vs MQTT Publish — Kontrol & Command

Web server ESP32 (#6) fokus pada GET (baca sensor). Di lapangan, kamu juga mungkin butuh kontrol aktuator — nyalakan relay, ubah setpoint, trigger OTA.

• REST POST/PUT: Klien kirim perintah ke endpoint /api/relay — cocok untuk aplikasi mobile yang sesekali toggle lampu
• MQTT publish ke topic kontrol: kodingindonesia/esp32/dht22/cmd — cocok untuk Node-RED (#23) dan Home Assistant (#21) yang sudah subscribe

MQTT unggul untuk event-driven control: banyak rule otomasi bisa subscribe topic yang sama. REST unggul jika partner eksternal hanya punya SDK HTTP.

Pola aman: pisahkan topic data (sensor) dan cmd (aktuator), dengan ACL berbeda di Mosquitto (#16) — publisher sensor tidak boleh publish ke topic relay.

Latency & Polling — Angka Kasar

Contoh: 5 dashboard polling REST tiap 2 detik = 150 request/menit ke ESP32. Satu MQTT publish tiap 30 detik = 2 message/menit dari device, fan-out gratis ke 5 subscriber.

Untuk sensor suhu greenhouse yang berubah lambat, polling 1 detik via REST adalah overkill. MQTT interval 30–60 detik lebih masuk akal — selaras dengan rekomendasi DHT22 minimal 2 detik antar pembacaan di #6.

Diagram Alur Data — REST vs MQTT

Visualisasi sederhana membantu tim memilih protokol sebelum menulis firmware:

REST (pull):
  [Browser] --GET /api/data--> [ESP32] --baca DHT22--> [JSON response]
  Interval polling = beban WiFi × jumlah klien

MQTT (push):
  [ESP32] --publish--> [Mosquitto] --fan-out--> [Grafana, Python, HA, Node-RED]
  Satu publish = banyak consumer tanpa ESP32 tahu siapa subscriber

Pada skenario REST, ESP32 harus selalu siap menerima HTTP jika kamu ingin data “live”. Pada MQTT, ESP32 cukup publish sesuai interval — subscriber yang bertanggung jawab menampilkan atau menyimpan.

Hybrid umum di produksi: ESP32 hanya MQTT outbound; backend (Laravel, FastAPI, Node) expose REST untuk partner eksternal yang tidak bisa subscribe MQTT langsung.

Uji Coba (Keduanya di Lab)

# REST — artikel #6
curl http://192.168.1.100/api/data

# MQTT — artikel #7
mosquitto_sub -h 192.168.1.50 -t "kodingindonesia/esp32/dht22/data" -v

1. Flash sketch #6 — curl http://192.168.1.100/api/data → JSON suhu
2. Flash sketch #7 — mosquitto_sub -h 192.168.1.50 -t "kodingindonesia/esp32/dht22/data" -v
3. Bandingkan: REST hanya kirim saat kamu curl; MQTT kirim tiap interval publish ESP32
4. Matikan broker — MQTT gagal connect; REST tetap jalan (independen)
5. Nyalakan subscriber #18 — hanya MQTT yang mengisi MySQL otomatis

FAQ Singkat

Bisakah ESP32 REST dan MQTT bersamaan?

Ya — RAM cukup untuk web server ringan + MQTT client. Prioritaskan satu path utama ke database agar tidak dobel insert.

MQTT butuh internet?

Tidak — broker Mosquitto di LAN (#16) sudah cukup untuk Grafana lokal (#19).

REST lebih aman dari MQTT?

Tidak otomatis. Keduanya butuh TLS (#17) dan autentikasi jika di-expose ke internet.

Kapan ganti dari REST ke MQTT?

Saat muncul kebutuhan kedua: histori otomatis (#18) atau dashboard kedua (#10 capstone sudah hybrid).

Tips & Troubleshooting

• REST lambat terasa: Normal — kamu yang harus refresh/polling; bukan bug ESP32
• MQTT data dobel di DB: Jangan jalankan REST scraper + MQTT subscriber ke DB yang sama tanpa dedup
• ESP32 overload: Jangan jalankan web server berat + MQTT TLS + OTA bersamaan di RAM terbatas — prioritaskan satu path data utama
• CORS / browser block: REST dari web app hosted beda origin butuh header CORS di handler ESP32 (topik lanjutan)
• Port 80 bentrok: Hanya satu layanan di port 80 — matikan web server jika fokus MQTT saja
• WiFi 2.4 GHz: ESP32 tidak support jaringan 5 GHz saja

Estimasi Biaya Infrastruktur

REST-only di ESP32 hampir tanpa biaya tambahan — cukup board + WiFi rumah. MQTT production menambah komponen opsional:

Untuk proyek hobi satu sensor, mulai REST (#6). Saat butuh histori dan multi-dashboard, investasi broker (#16) lebih masuk akal daripada membangun banyak scraper HTTP.

Ringkasan Jalur B — REST vs MQTT dalam Stack

Di Seri 2, urutan belajar umumnya:

1. #6 — REST lokal untuk prototipe cepat
2. #7 + #16 — MQTT sebagai bus data utama
3. #17 — TLS untuk MQTT di internet
4. #18 / #19 — histori SQL atau grafik Grafana
5. #20 (artikel ini) — keputusan arsitektur sebelum scale

REST tidak “kalah” dari MQTT — ia lebih sederhana di tahap awal. MQTT unggul saat data harus mengalir ke banyak sistem tanpa ESP32 menjadi bottleneck.

Keamanan & Produksi

• Jangan commit password WiFi/MQTT ke GitHub — pakai NVS/WiFiManager (#12)
• Placeholder GANTI_PASSWORD_MQTT — ganti sebelum deploy lapangan
• Expose REST tanpa auth hanya di VLAN sensor terpisah
• Audit trail: MQTT + timestamp (#34) lebih mudah di-log ke DB daripada polling REST acak

Langkah Selanjutnya (Seri 2)

• ESP-NOW (#25): komunikasi antar ESP32 tanpa router WiFi
• Broker Mosquitto (#16) — fondasi MQTT production
• InfluxDB + Grafana (#19) — visualisasi setelah pilih MQTT
• MQTT TLS (#17) — amankan push data di internet
• Capstone greenhouse (#39) — hybrid sensor MQTT + dashboard Grafana

Memahami REST vs MQTT membantu kamu memilih alat yang tepat, bukan memaksakan satu protokol untuk semua lapisan. Lanjutkan Seri 2 di halaman artikel Koding Indonesia.