DEV Community

Cover image for API Plattform für IoT Entwicklung
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

API Plattform für IoT Entwicklung

TL;DR

IoT-APIs stellen Anforderungen, die viele Standard-API-Tools herausfordern: eingeschränkte Bandbreite, binäre Nutzdaten, gerätespezifische Authentifizierung und Protokolle, die nicht HTTP-basiert sind. Dieser Artikel zeigt, was IoT-Entwickler von API-Tools benötigen, wo Tools wie Apidog eingesetzt werden können, welche Grenzen sie haben (z.B. MQTT) und wie Sie die HTTP-Schicht Ihres IoT-Backends effektiv testen.

Testen Sie Apidog noch heute

💡 Apidog ist eine kostenlose All-in-One-Plattform für API-Entwicklung. Für IoT-Entwickler verwaltet Apidog die HTTP- und WebSocket-Ebenen Ihres Backends – REST-Bereitstellung, binäre Nutzlasttests, benutzerdefinierte Auth-Header und SSL/TLS-Konfiguration. Apidog kommuniziert ehrlich, welche Protokolle es nicht abdeckt. Sie können Apidog sofort kostenlos testen, keine Kreditkarte erforderlich.

Einleitung

IoT-Entwicklung ist zweigeteilt: Die geräteorientierte Schicht nutzt MQTT, CoAP, binäre Protokolle und WebSocket-Streams – optimiert für Bandbreite und Energie. Die plattformorientierte Schicht setzt auf REST-APIs für Gerätebereitstellung, Firmware-Updates, Telemetrie und Management – wie klassische Web-Backends.

Standard-API-Tools bedienen die Plattformschicht gut, die Geräteschicht wird meist ignoriert. MQTT-Tests sind nicht in universellen API-Tools zu erwarten. Entscheidend ist, welche Protokolle Ihr Tool abdeckt, wie Sie diese optimal nutzen und wann spezialisierte Tools nötig sind.

In diesem Artikel: Überblick IoT-Protokolle, was Apidog abdeckt und praktisches Test-Setup für die HTTP-Teile Ihres IoT-Backends.

Die IoT-Protokolllandschaft

MQTT: Publish-Subscribe für Geräte

MQTT ist Standard für Geräte-Cloud-Kommunikation: robust bei instabilen Netzen, minimaler Overhead, effizientes Routing über Broker.

Konzepte: Topics, QoS-Level, retained messages, Last Will and Testament (LWT).

Achtung: Apidog unterstützt MQTT nicht nativ. Nutzen Sie für MQTT-Tests:

  • MQTT Explorer: GUI-Tool für Broker-Interaktion
  • MQTTX: Cross-Plattform-Client mit Scripting
  • mosquitto_sub/mosquitto_pub: CLI-Tools (Mosquitto-Projekt)
  • HiveMQ Broker: Cloud-Broker mit Web-Client

Für MQTT-basierte Systeme benötigen Sie immer ein dediziertes MQTT-Testtool neben Ihrem REST-Testtool.

HTTP/REST: die Plattformschicht

REST-APIs sind Standard für:

  • Gerätebereitstellung (Registrierung, Zertifikate, IDs)
  • OTA-Firmware-Updates
  • Konfigurations-Push
  • Telemetrie-Erfassung (teils via HTTP POST)
  • Geräteverwaltung
  • Datenabfrage (z.B. Telemetrie, Logs)
  • Webhook-Registrierung

Diese APIs können Sie problemlos mit Tools wie Apidog automatisiert testen.

WebSocket: bidirektionale Gerätekommunikation

WebSocket ist zwischen REST und MQTT angesiedelt. Einsatz für:

  • Gerätebefehle in Echtzeit
  • Live-Telemetrie-Streams
  • Bidirektionale Konfigurationsupdates

Apidog unterstützt WebSocket-Tests und individuelle Verbindungsheader – ideal für die meisten WebSocket-IoT-Fälle.

CoAP: eingeschränkte Geräte

CoAP ist HTTP-ähnlich, läuft aber über UDP und ist für Mikrocontroller entwickelt.

Achtung: Apidog unterstützt CoAP nicht. Für CoAP-Tests: copper4cr (Browser-Addon) oder libcoap (CLI).

Binäre Nutzdaten

Viele IoT-Systeme setzen auf binäre Kodierung (Protocol Buffers, MessagePack, CBOR), um Bandbreite zu sparen.

Apidog unterstützt rohe binäre HTTP-Bodies – senden Sie hex- oder base64-kodierte Payloads, wenn Ihre Plattform HTTP für Binärdaten nutzt.

Geräte-Authentifizierungsmuster im IoT

IoT-Auth unterscheidet sich von klassischer API-Auth. Neben OAuth 2.0, Bearer-Tokens und API-Schlüsseln gibt es:

Mutual TLS (mTLS)

Viele Plattformen (AWS IoT, Azure IoT Hub, Google Cloud IoT Core) verlangen mTLS: Jedes Gerät hat ein Client-Zertifikat, das beim Verbindungsaufbau präsentiert wird.

Test: In Apidog können Sie Client-Zertifikat und Key für mTLS konfigurieren.

Gerätespezifische API-Schlüssel

Manche Plattformen verwenden API-Schlüssel/Token pro Gerät. Diese können Sie als Header oder Bearer-Token wie gewohnt in Apidog verwenden.

JWT mit Geräte-Claims

Plattformen geben JWTs mit Claims wie Geräte-ID, Modell, Firmware-Version aus. Standard-JWT-Auth (z.B. per Bearer-Token) funktioniert. Die Token-Verwaltung kann per Pre-Request-Skript automatisiert werden.

Benutzerdefinierte Header-Authentifizierung

Einige Plattformen nutzen proprietäre Auth-Header (z.B. X-Device-Token). Apidog unterstützt beliebige Custom-Header.

Testen von IoT-REST-APIs mit Apidog

Hier punktet Apidog bei der Entwicklung und beim Testen von IoT-Backends.

Gerätebereitstellungs-Workflows

Ein typischer Workflow:

  1. Gerät registrieren (POST mit Seriennummer, Modell, Firmware)
  2. Geräte-ID + Anmeldeinfos aus Antwort extrahieren
  3. Gerät mit erhaltenen Daten konfigurieren
  4. Status abrufen (GET)

Umsetzung: In Apidog können Sie mit Post-Request-Skripten z.B. die Geräte-ID extrahieren und als Variable speichern. Die nächsten Requests nutzen diese Variable automatisch. So laufen komplette Workflows als Testkette durch.

OTA-Firmware-Update-Endpunkte

Typischer Ablauf:

  1. GET /devices/{id}/update-check
  2. GET /devices/{id}/firmware (liefert URL oder Binärdaten)
  3. POST /devices/{id}/update-status

Tipps: Überprüfen Sie bei binären Firmware-Antworten die Header (Content-Type, Content-Length) und das Datenformat.

Telemetrie-Erfassung über HTTP

Viele Plattformen akzeptieren Telemetrie per HTTP POST, oft als Binärformat.

So testen Sie binäre Telemetrie in Apidog:

  1. Anfragetyp auf raw setzen
  2. Body-Format: binary wählen
  3. Hex- oder base64-kodierte Payload einfügen
  4. Content-Type: application/octet-stream setzen
  5. Senden und Antwort prüfen

Für Protobuf: Payload extern kodieren und einfügen. Apidog übernimmt den Transport, nicht die Kodierung.

Testen mit benutzerdefinierten SSL-Zertifikaten

IoT-Backends nutzen oft selbstsignierte Zertifikate oder mTLS.

Mit Apidog können Sie:

  • SSL-Verifizierung für lokale Entwicklung deaktivieren
  • Eigenes CA-Zertifikat laden
  • Client-Zertifikat für mTLS nutzen

Empfehlung: In der Entwicklung SSL-Check deaktivieren, für Produktion das CA-Zertifikat laden.

WebSocket-Tests für IoT-Gerätestreams

Moderne IoT-Plattformen bieten WebSocket-Endpoints für:

  • Geräte-Shadow / Twin-Streams: Status- und Shadow-Updates per Stream
  • Live-Telemetrie: Sensordaten in Echtzeit ans Dashboard
  • Befehlsübermittlung: Echtzeit-Kommandos an Geräte

So testen Sie das mit Apidog:

  1. Mit WebSocket-URL und Auth-Header verbinden
  2. Abonnementnachricht senden (falls nötig)
  3. Eingehende Nachrichten im Log beobachten
  4. Test-Kommandos senden und Geräteverhalten prüfen

Hinweis: Subprotokolle (Sec-WebSocket-Protocol) werden unterstützt.

Was für MQTT-Tests verwendet werden sollte

Da Apidog MQTT nicht abdeckt, hier ein praxistaugliches Setup:

  • MQTTX: Umfassender Desktop-Client mit Scripting, TLS/mTLS, alle Protokollversionen
  • MQTT Explorer: Visualisiert Themenbäume und Nachrichtenströme
  • mosquitto CLI-Tools: Schnelle Skripttests, ideal für Automatisierung und CI/CD

Für automatisierte Tests und Integration empfiehlt sich sprachnativer Testcode (z.B. paho-mqtt für Python, MQTT.js für Node.js).

Praktisches IoT-Backend-Test-Setup

Apidog Umgebungsstruktur:

Environments:
  local-dev: base_url = http://localhost:8080, ssl_verify = false
  staging: base_url = https://iot-staging.example.com, ssl_verify = true
  prod: base_url = https://api.iot.example.com, ssl_verify = true

Variables:
  device_id = dev_test_001
  device_serial = SN-TEST-00001
  auth_token = {{fetched via pre-request script}}
  firmware_version = 2.1.4
Enter fullscreen mode Exit fullscreen mode

Ordnerstruktur:

  • provisioning/ – Geräte-Registrierung & Credentials-Workflows
  • telemetry/ – Erfassungsendpunkte (JSON/binär)
  • ota/ – Firmware-Update-Check & Bereitstellung
  • device-management/ – CRUD-Operationen für Geräte
  • websocket/ – Echtzeit-Verbindungstests
  • error-cases/ – Tests für Fehlerfälle: ungültige Auth, abgelaufene Tokens, fehlerhafte Payloads

Checkliste für binäre Nutzlasten:

  • Gültige binäre Nutzlast (Happy Path)
  • Abgeschnittene Nutzlast (unvollständig)
  • Falscher Content-Type
  • Maximale Payloadgröße testen
  • Korrekte & inkorrekte Geräteauthentifizierung prüfen

FAQ

Unterstützt Apidog MQTT-Tests?

Nein. Apidog bietet keine native MQTT-Unterstützung. Für MQTT-Tests nutzen Sie MQTTX, MQTT Explorer oder mosquitto CLI. Apidog deckt HTTP- und WebSocket-Schichten ab, nicht die MQTT-Broker-Schicht.

Kann Apidog CoAP-Endpunkte testen?

Nein. CoAP läuft über UDP, was Apidog nicht unterstützt. Nutzen Sie copper4cr oder libcoap.

Wie teste ich binäre Protobuf-Payloads in Apidog?

Mit Ihrer Programmiersprache die Protobuf-Nachricht binär kodieren und dann in Hex/Base64 umwandeln. In Apidog Body auf Raw Binary stellen, Payload einfügen, Content-Type anpassen (application/protobuf oder spezifisch).

Unterstützt Apidog mTLS für Geräte-Zertifikatsauthentifizierung?

Ja. In den SSL-Einstellungen können Sie Client-Zertifikat und privaten Schlüssel für mTLS hochladen.

Können wir Apidog für AWS IoT Core, Azure IoT Hub oder Google Cloud IoT testen?

Ja, für die HTTP/REST-APIs dieser Plattformen. MQTT-Verbindungen benötigen jedoch ein dediziertes MQTT-Tool.

Was ist der beste Ansatz zum Testen binärer Telemetrie-Kodierung?

Erstellen Sie Testdaten (gültig, abgeschnitten, fehlerhaft) mit Ihrer Kodierungsbibliothek, speichern Sie sie als Variable oder Datei. Senden Sie die Payloads mit Apidog an den Endpunkt und prüfen Sie Antwortcodes und Verhalten.

IoT-Backend-Testing erfordert meist zwei Tools: eins für MQTT und eins für REST/WebSocket. Apidog deckt die HTTP-Schicht zuverlässig ab – Provisionierung, Management, Telemetrie, Binärdaten, mTLS, WebSocket. Für MQTT empfiehlt sich MQTTX oder Mosquitto. Das Wissen, welches Tool wann einzusetzen ist, bringt Sie weiter als der Versuch, alles in einem Tool abzudecken.

Top comments (0)