Daten verarbeiten mit Node-RED: APIs, JSON & Webhooks richtig integrieren

Daten verarbeiten – APIs, JSON & Webhooks

Node-RED als Integrationszentrale (API-Broker statt Klickskript)

Ziel: Node-RED als Integrationszentrale verstehen Ergebnis: Du setzt Node-RED gezielt als API-Broker ein – stabil, nachvollziehbar, wartbar.

1. HTTP In & HTTP Request: Ein- und Ausgang der Welt

Node-RED wird dann richtig stark, wenn es zwischen Systemen vermittelt. Genau dafür sind die beiden zentralen HTTP-Nodes da.

HTTP In – dein Eingangstor

Der HTTP In-Node macht Node-RED selbst zur API:

• Webhooks empfangen
• eigene REST-Endpunkte bereitstellen
• Trigger aus externen Systemen annehmen

Wichtiges Denkmodell: HTTP In ist kein Controller im klassischen Sinn, sondern ein Trigger für einen Prozess.

👉 Behandle jeden HTTP-In-Flow wie einen Eingangskanal, nicht wie eine Anwendung.

HTTP Request – dein Ausgangstor

Mit HTTP Request sprichst du andere Systeme an:

• REST-APIs
• Webservices
• interne Dienste
• Cloud-APIs

Best Practices:

• URL, Methode und Header klar definieren
• Timeouts setzen
• Antwort bewusst auswerten

👉 Node-RED ist hier kein „API-Client“, sondern ein Orchestrator.

2. REST-APIs anbinden: Denken in Verträgen, nicht in Calls

REST-APIs sind Verträge:

• Struktur
• Erwartung
• Antwortformat
• Fehlerfälle

Node-RED zwingt dich, diese Verträge sichtbar zu machen:

• Request
• Transformation
• Reaktion

Typischer sauberer Ablauf

1. Eingang (HTTP In / Inject)
2. Vorbereitung (Header, Parameter)
3. API-Aufruf (HTTP Request)
4. Auswertung (Statuscode, Body)
5. Weiterverarbeitung oder Antwort

👉 Gute Flows spiegeln die API-Logik – schlechte verstecken sie.

3. JSON zerlegen & transformieren: Ordnung statt Datenmüll

APIs sprechen fast immer JSON. Das Problem ist selten das Format – sondern die Struktur.

Anfängerfehler

• alles in msg.payload lassen
• wild verschachtelte Objekte
• keine klare Zielstruktur

Besser:

• JSON gezielt zerlegen
• relevante Felder extrahieren
• eigene, saubere Struktur bauen

Change- & Switch-Nodes sind hier oft besser als Function-Nodes:

• deklarativ
• sichtbar
• wartbar

👉 Ziel ist nicht „Daten rein“, sondern Daten passend machen.

4. Authentifizierung: Tokens, Header & Realität

Fast jede API will heute:

• API-Keys
• Bearer-Tokens
• spezielle Header

Node-RED kann das – aber Disziplin ist Pflicht.

Best Practices

• Credentials nicht hart im Flow
• keine Tokens im Klartext
• Header bewusst setzen
• Auth-Logik kapseln

👉 Denk in Zugriffsschichten, nicht in Einzellösungen.

Node-RED ist hier kein Sicherheitsrisiko – schlampige Flows sind es.

5. Fehlerhandling bei APIs: Der Unterschied zwischen Demo & Betrieb

Der größte Unterschied zwischen „funktioniert“ und „professionell“ ist Fehlerbehandlung.

Typische API-Fehler

• Timeout
• 4xx / 5xx Statuscodes
• ungültiges JSON
• leere Antworten
• Rate Limits

Schlechte Reaktion

„Debug zeigt rot – naja.“

Gute Reaktion

• Statuscodes auswerten
• alternative Pfade
• klare Fehlermeldungen
• definierte Antworten nach außen

👉 Ein guter Flow erwartet Fehler – und bricht nicht daran.

Fazit: Node-RED als API-Broker, nicht als Skript

Wenn du Node-RED richtig einsetzt:

• bündelt es APIs
• entkoppelt Systeme
• übersetzt Daten
• stabilisiert Prozesse

Dann ist es:

• kein Basteltool
• kein Klick-Workflow
• sondern eine Integrationsschicht

👉 Node-RED wird dann zum API-Broker, der:

• eingehende Signale versteht
• externe Systeme koordiniert
• und klare Antworten liefert