Ein n8n-Schritt scheitert, und die Fehlermeldung sagt nur „400 Bad Request“. Dahinter steckt ein Muster, das jeder Austausch zwischen zwei Systemen gleich durchläuft.
Wer automatisiert, stößt unweigerlich auf HTTP, das Protokoll, mit dem Programme im Netz Nachrichten austauschen. Ohne dessen Aufbau zu kennen, rät man beim Debuggen im Blindflug herum.
Jede HTTP-Kommunikation folgt demselben Muster: Der Client, also das fragende System, schickt eine Anfrage; der Server antwortet einmal darauf. Die Anfrage besteht aus vier Teilen. Die Methode sagt, was geschehen soll: GET fordert eine Ressource an, POST übergibt Daten zur Verarbeitung, PUT ersetzt sie vollständig, DELETE löscht sie. Die Header tragen Zusatzangaben, etwa einen API-Schlüssel – eine geheime Zeichenfolge, mit der sich das Programm gegenüber einer API, der Programmschnittstelle eines Systems, ausweist. Der Body enthält die zu übergebenden Daten; bei GET bleibt er meist leer.
Ein Beispiel: n8n soll Daten an eine Tabellenkalkulation senden. Der Schritt „HTTP Request“ braucht Methode POST, die Ziel-URL aus der Dokumentation, im Header den API-Schlüssel und im Body die Daten. Klappt es nicht, gilt: erst den Statuscode der Antwort lesen. 200 heißt Erfolg, 404, dass es das Ziel nicht gibt, 401, dass der Ausweis fehlt, 500, dass der Server versagte.
Verwechselt wird HTTP gern mit der Schnittstelle selbst. Eine API ist das Angebot eines Systems; HTTP ist nur die Transportart. Auch 4xx und 5xx werden vermischt: 4xx verweist auf die eigene Anfrage, 5xx auf das fremde System – beides braucht unterschiedliche Maßnahmen.
HTTP ist nicht geheimnisvolles Unglück, sondern ein Brief mit Methode, Adresse, Kopfzeilen und Inhalt. Wer die vier Teile kennt, ordnet jeden Fehler einer Ursache zu.
📌 Methode und URL · Header mit Ausweis · Statuscode lesen
📚 Automatisierung von Grund auf · Tag 2 von 30
#Automatisierung #api #n8n #Webhooks
Wer automatisiert, stößt unweigerlich auf HTTP, das Protokoll, mit dem Programme im Netz Nachrichten austauschen. Ohne dessen Aufbau zu kennen, rät man beim Debuggen im Blindflug herum.
Jede HTTP-Kommunikation folgt demselben Muster: Der Client, also das fragende System, schickt eine Anfrage; der Server antwortet einmal darauf. Die Anfrage besteht aus vier Teilen. Die Methode sagt, was geschehen soll: GET fordert eine Ressource an, POST übergibt Daten zur Verarbeitung, PUT ersetzt sie vollständig, DELETE löscht sie. Die Header tragen Zusatzangaben, etwa einen API-Schlüssel – eine geheime Zeichenfolge, mit der sich das Programm gegenüber einer API, der Programmschnittstelle eines Systems, ausweist. Der Body enthält die zu übergebenden Daten; bei GET bleibt er meist leer.
Ein Beispiel: n8n soll Daten an eine Tabellenkalkulation senden. Der Schritt „HTTP Request“ braucht Methode POST, die Ziel-URL aus der Dokumentation, im Header den API-Schlüssel und im Body die Daten. Klappt es nicht, gilt: erst den Statuscode der Antwort lesen. 200 heißt Erfolg, 404, dass es das Ziel nicht gibt, 401, dass der Ausweis fehlt, 500, dass der Server versagte.
Verwechselt wird HTTP gern mit der Schnittstelle selbst. Eine API ist das Angebot eines Systems; HTTP ist nur die Transportart. Auch 4xx und 5xx werden vermischt: 4xx verweist auf die eigene Anfrage, 5xx auf das fremde System – beides braucht unterschiedliche Maßnahmen.
HTTP ist nicht geheimnisvolles Unglück, sondern ein Brief mit Methode, Adresse, Kopfzeilen und Inhalt. Wer die vier Teile kennt, ordnet jeden Fehler einer Ursache zu.
📌 Methode und URL · Header mit Ausweis · Statuscode lesen
📚 Automatisierung von Grund auf · Tag 2 von 30
#Automatisierung #api #n8n #Webhooks
4 Tage vor
