Schnittstellen und Übertragungsverfahren: Push und Pull, synchron und asynchron

Schnittstellen und Übertragungsverfahren: Push und Pull, synchron und asynchron

https://bildung.social/@oerinformatik/

https://oer-informatik.de/schnittstellen-uebertragungsverfahren

Schnittstelle, Push, Pull, Polling, Webhook, synchron, asynchron, Message Broker, Warteschlange, Batch-Schnittstelle, ereignisgesteuert, Heartbeat

tl/dr; (ca. 21 min Lesezeit): Wenn zwei Systeme Daten austauschen, musst Du drei Fragen beantworten: Wer ergreift die Initiative (Push oder Pull)? Wann wird gesendet (in festen Abständen oder bei einem Ereignis)? Und wartet der Sender auf eine Antwort (synchron oder asynchron)? Du lernst Polling, Webhooks und Publish/Subscribe kennen, siehst, warum asynchrone Nachrichten sich überholen können und wie Sequenznummern, Zeitstempel, Warteschlangen und Message Broker die Reihenfolge retten. Zum Schluss vergleichst Du synchrone mit job-orientierten Schnittstellen und ordnest typischen Übertragungsfehlern passende Gegenmaßnahmen zu [AI-Assisted]. (Zuletzt geändert am 29.10.2026)

Dieser Artikel ist Teil einer Artikelreihe zu Schnittstellen und vernetzten Systemen: REST-API und HTTP / Schnittstellen und Übertragungsverfahren / Übungsaufgaben zu Schnittstellen und Übertragungsverfahren

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Dieser Artikel baut auf der Kann-Liste des Artikels REST-API und HTTP auf.

Als Grundlagen zu Schnittstellen und Übertragungsverfahren kann ich nach Durchlesen des Artikels…

• … beschreiben, was eine Schnittstelle zwischen zwei Systemen festlegt (Protokoll, Datenformat, Ablauf, Fehlerverhalten), und an einem Auftrag vom Onlineshop bis zur Maschine erläutern, welche Daten an welcher Schnittstelle fließen.

• … die Unterschiede zwischen Push- und Pull-Verfahren beschreiben und Polling, Webhook und Publish/Subscribe einordnen.

• … begründen, ob in einer Situation Push oder Pull geeignet ist.

• … zyklische (intervallgesteuerte) und ereignisgesteuerte Übertragung unterscheiden und die Risiken beider Verfahren erläutern.

• … synchrone und asynchrone Kommunikation unterscheiden und im Sequenzdiagramm erkennen.

Darüber hinaus kann ich als Profilwissen für vernetzte Systeme…

• … erläutern, wie asynchron gesendete Nachrichten in vertauschter Reihenfolge verarbeitet werden können.

• … Möglichkeiten erläutern, die Verarbeitungsreihenfolge zu sichern (Sequenznummern, Versionszähler, Broker-Partitionen, Zeitstempel der Erzeugung, synchrone Bestätigung).

• … synchrone und job-orientierte Schnittstellen vergleichen (Ergebnis, Fehlerbehandlung beim Aufrufer, Bündelung, Lastspitzen, Aufwand) und für eine Situation begründet auswählen.

• … Zustellgarantien (höchstens einmal, mindestens einmal, genau einmal) unterscheiden und erläutern, warum Empfänger idempotent sein sollten.

• … für Fehler auf dem Weg einer Nachricht (verfälscht, verloren, doppelt, vertauscht, abgehört, gefälscht, Empfänger nicht erreichbar) passende Gegenmaßnahmen auswählen.

• … die Netzlast von Polling und Push abschätzen und daraus eine Entscheidung ableiten.

Ein Onlineshop nimmt die Bestellung eines Fahrradrahmens nach Maß an. Die Warenwirtschaft (ERP) legt einen Auftrag an und schickt ihn an das Fertigungssystem (MES) eines Partnerbetriebs, das MES verteilt die Arbeitsschritte an die Steuerungen der Maschinen. Später will der Shop wissen, ob der Rahmen fertig ist, und die Kundin möchte eine Versandmeldung. An jeder dieser Stellen tauschen zwei Systeme Daten über eine Schnittstelle aus – und an jeder Stelle stellt sich dieselbe Frage: Wie kommen die Daten vom einen System zum anderen?

Die Mindmap zeigt die drei Fragen, um die es in diesem Artikel geht, und die übrigen Themen im Überblick:

Was eine Schnittstelle festlegt

Eine Schnittstelle (engl. interface) ist die vereinbarte Stelle, an der zwei Systeme Daten austauschen. Bei Software spricht man meist von einer API (Application Programming Interface). Eine Schnittstelle legt fest:

• Protokoll und Transportweg: z. B. HTTP bei einer REST-API, MQTT, OPC UA oder eine Datei, die per SFTP abgelegt wird.

• Datenformat: z. B. JSON, XML oder CSV (siehe Datenaustauschformate).

• Ablauf: Wer beginnt die Kommunikation? Wann wird gesendet? Wartet der Sender auf eine Antwort?

• Fehlerverhalten: Was passiert, wenn der Empfänger nicht erreichbar ist, eine Nachricht verloren geht oder doppelt ankommt?

Die ersten beiden Punkte sind Thema eigener Artikel. Hier geht es um den Ablauf und das Fehlerverhalten – die Übertragungsverfahren.

Schnittstellen entlang eines Auftrags

Im Beispiel vom Anfang durchläuft der Rahmen nach Maß mehrere Systeme. An jedem Übergang werden andere Daten übertragen, und jeder Übergang stellt andere Anforderungen an das Übertragungsverfahren:

Der Auftrag läuft dabei von der Planung (Shop, ERP) über die Fertigungssteuerung (MES) bis zur Ausführung (Steuerung, Maschine) – das entspricht den Ebenen der Automatisierungspyramide. Messwerte und Fertigmeldungen laufen in umgekehrter Richtung zurück. Welches Verfahren an welchem Übergang passt, klären die folgenden Abschnitte.

Push und Pull: Wer ergreift die Initiative?

Die erste Frage lautet: Welches System beginnt die Übertragung?

• Push: Der Sender (die Datenquelle) übermittelt seine Daten auf eigene Initiative, sobald sie vorliegen oder ein Zeitpunkt erreicht ist. Der Empfänger wartet passiv.

• Pull: Der Empfänger fordert die Daten an, wenn er sie braucht. Die Datenquelle sendet nur auf Anfrage.

Ein Alltagsvergleich: Eine Push-Nachricht auf dem Smartphone kommt von selbst; beim Pull öffnest Du die App und lädst neu.

Polling: Pull in regelmäßigen Abständen

Will ein Empfänger mit Pull von Änderungen erfahren, muss er immer wieder nachfragen. Dieses wiederholte Abfragen heißt Polling. Polling ist einfach umzusetzen (eine gewöhnliche GET-Anfrage genügt), hat aber zwei Nachteile:

• Verzögerung: Eine Änderung fällt erst bei der nächsten Abfrage auf – im Mittel nach dem halben Abfrageintervall, im ungünstigsten Fall nach einem ganzen.

• Last: Die meisten Anfragen liefern „nichts Neues“. Ein Beispiel: Fragt die Warenwirtschaft für 140 offene Aufträge alle 5 Minuten den Status ab, sind das 140 · 12 · 24 = 40.320 Anfragen am Tag. Ändert sich jeder Status nur rund dreimal, würden mit Push 140 · 3 = 420 Meldungen genügen.

Eine Variante ist Long Polling: Der Server hält die Anfrage offen, bis neue Daten vorliegen oder eine Wartezeit abläuft. Das verringert die Verzögerung, bindet aber Verbindungen.

Push-Techniken

• Webhook: Der Empfänger meldet beim Sender einmal eine URL an (Abonnement). Tritt ein Ereignis ein, ruft der Sender diese URL mit einem POST auf. Der Empfänger muss dafür aus dem Netz des Senders erreichbar sein.

• Server-Sent Events und WebSockets: Der Client baut eine dauerhafte Verbindung auf, über die der Server jederzeit Daten schicken kann – typisch für Live-Anzeigen im Browser.

• Publish/Subscribe: Sender (Publisher) schicken Nachrichten an einen Broker, Empfänger (Subscriber) abonnieren Themen; der Broker verteilt. Bekanntestes Beispiel ist MQTT. Sender und Empfänger kennen sich nicht und müssen nicht gleichzeitig online sein.

Push oder Pull? Ein Vergleich

Push lohnt sich, wenn viele Datenquellen selten, aber dann zeitkritisch etwas melden (Positionen von Fahrzeugen, Alarme), und wenn die Quelle nach einer kurzen Unterbrechung selbstständig weitermachen soll. Pull passt, wenn der Empfänger den Zeitpunkt bestimmen will (nächtlicher Bericht), wenn die Quelle einfach und passiv bleiben soll oder wenn der Empfänger nicht von außen erreichbar ist.

Zyklisch oder ereignisgesteuert: Wann wird gesendet?

Die zweite Frage betrifft den Zeitpunkt der Übertragung. Sie stellt sich vor allem bei Push.

• Zyklische Übertragung (Intervall): Die Quelle sendet in festen Abständen, z. B. alle 10 Minuten alle seit der letzten Übertragung gesammelten Messwerte.

• Ereignisgesteuerte Übertragung: Die Quelle sendet nur, wenn etwas Bestimmtes passiert, z. B. ein Grenzwert überschritten wird (Alarm), ein Schloss geöffnet wird oder sich ein Wert um mehr als eine Schwelle ändert (Deadband, report by exception).

Beide Verfahren haben typische Risiken:

Verfahren	Risiko	Erläuterung	Gegenmaßnahme
zyklisch	späte Erkennung	Eine Grenzwertüberschreitung wird erst mit der nächsten Übertragung gemeldet, also bis zu ein Intervall zu spät – Ware kann in dieser Zeit schon verdorben sein.	kürzeres Intervall oder zusätzlich Alarm bei Grenzwert
zyklisch	Datenverlust	Scheitert eine Übertragung und löscht die Quelle die Daten trotzdem, fehlen die Messwerte eines ganzen Intervalls.	Daten erst nach Bestätigung löschen, Puffer für mehrere Intervalle
zyklisch	Fehler an der Quelle	Ein defekter Sensor fällt frühestens nach einem Intervall auf.	Plausibilitätsprüfung, kürzeres Intervall
ereignisgesteuert	stiller Ausfall	Fällt die Quelle aus (Akku leer, Defekt), sendet sie nichts – und „nichts“ sieht aus wie „alles in Ordnung“.	Heartbeat (Lebenszeichen in festen Abständen), Überwachung „letzte Meldung vor mehr als …“
ereignisgesteuert	verlorener Alarm	Geht genau die eine Alarmmeldung bei einer Funkstörung verloren, wird der Alarm nie erkannt.	Bestätigung (ACK) und Wiederholung, Zustellgarantie „mindestens einmal“
ereignisgesteuert	Meldungsflut	Schwankt ein Wert um den Grenzwert, entstehen sehr viele Alarme.	Hysterese bzw. Mindestabstand zwischen Meldungen

In der Praxis kombiniert man beide: ein langes Grundintervall mit Heartbeat plus sofortige Ereignismeldungen. So erkennst Du Grenzwerte schnell und bemerkst trotzdem, wenn eine Quelle verstummt.

Synchron und asynchron: Wartet der Sender?

Die dritte Frage lautet: Wartet der Sender auf eine Antwort, bevor er weiterarbeitet?

• Synchrone Kommunikation: Der Sender schickt eine Anfrage und wartet blockierend, bis die Antwort (oder ein Timeout) eintrifft. Erst dann sendet er die nächste Nachricht. Beispiel: Ein Shop prüft während des Bestellvorgangs per REST-Aufruf, ob ein Schloss lieferbar ist, und zeigt das Ergebnis sofort an.

• Asynchrone Kommunikation: Der Sender schickt die Nachricht ab und arbeitet sofort weiter, ohne auf eine Antwort zu warten (fire and forget). Eine Reaktion kommt – falls überhaupt – später als eigene Nachricht (Rückruf, Callback).

Im UML-Sequenzdiagramm erkennst Du den Unterschied an der Pfeilspitze: Synchrone Nachrichten haben eine gefüllte Pfeilspitze und eine gestrichelte Antwort, asynchrone Nachrichten eine offene Pfeilspitze und keine Antwort.

Warum asynchrone Nachrichten sich überholen

Bei asynchroner Kommunikation werden Nachrichten unabhängig voneinander übertragen. Nichts sorgt dafür, dass die zuerst gesendete Nachricht auch zuerst ankommt. Ursachen für eine vertauschte Reihenfolge:

• unterschiedliche Laufzeiten im Netz: Pakete nehmen verschiedene Wege, werden in Warteschlangen von Routern unterschiedlich lange gehalten oder im Mobilfunknetz priorisiert.

• Wiederholungen: Eine Nachricht geht verloren und wird nach einem Timeout erneut gesendet – inzwischen ist die nächste längst angekommen.

• parallele Verarbeitung: Beim Sender senden oder beim Empfänger verarbeiten mehrere Threads bzw. Instanzen gleichzeitig; eine schnellere Instanz überholt eine langsamere.

• Priorisierung: Eine Warteschlange arbeitet wichtige Nachrichten zuerst ab, eine ältere, weniger wichtige Nachricht kommt später dran.

Das ist kein Fehler des Netzes, sondern eine Eigenschaft asynchroner Übertragung. Wenn die Reihenfolge fachlich wichtig ist (Schloss „geöffnet“ → „geschlossen“), musst Du sie selbst sichern.

Die Reihenfolge sichern

Maßnahme	So funktioniert sie	Preis
Sequenznummer	Jede Nachricht trägt eine fortlaufende Nummer je Quelle; der Empfänger verarbeitet in Nummernfolge, wartet auf Lücken oder verwirft Veraltetes.	Empfänger muss je Quelle die letzte Nummer kennen
Versionszähler am Datensatz	Der Empfänger führt je Datensatz (z. B. je Auftrag) eine Versionsnummer. Jede Änderung nennt die Version, auf der sie aufbaut (bei HTTP z. B. per ETag und If-Match); passt sie nicht mehr, wird die Änderung abgelehnt, statt einen neueren Stand zu überschreiben.	Sender muss abgelehnte Änderungen neu einlesen und erneut senden
Broker mit Partitionen	Nachrichten mit demselben Schlüssel (z. B. Auftragsnummer) landen im Broker immer in derselben Partition; innerhalb einer Partition liefert der Broker in Reihenfolge aus, verschiedene Partitionen laufen parallel.	Reihenfolge nur je Schlüssel; zusätzliches System, das betrieben und abgesichert werden muss
Zeitstempel der Erzeugung	Die Quelle stempelt jede Nachricht; der Empfänger ordnet nach diesem Zeitstempel statt nach der Ankunftszeit.	Uhren müssen synchron laufen (NTP), gleiche Zeitstempel möglich
synchron senden	Der Sender schickt die nächste Nachricht erst, wenn die vorige bestätigt ist.	geringerer Durchsatz, Sender blockiert bei Netzproblemen

Häufig reicht es, den letzten bekannten Zustand nur dann zu überschreiben, wenn die neue Meldung eine höhere Sequenznummer bzw. einen jüngeren Zeitstempel hat.

Synchrone und job-orientierte Schnittstellen

Viele Dienste (Zahlungsdienste, Versanddienstleister, Fertigungspartner) bieten zwei Arten von Schnittstellen an:

• Synchrone Schnittstelle: Jede Anfrage wird sofort verarbeitet, die Antwort enthält das Ergebnis. Beispiel: POST /auftraege liefert 201 Created mit der Auftragsnummer.

• Job-orientierte Schnittstelle (asynchron, Batch): Der Aufrufer übergibt einen Auftrag (Job), der in eine Warteschlange kommt. Die Antwort bestätigt nur die Annahme, z. B. 202 Accepted mit einer Job-ID. Das Ergebnis holt der Aufrufer später ab (Pull: GET /jobs/{id}) oder bekommt es per Webhook (Push). Viele Datensätze lassen sich in einem Job bündeln.

Welche Variante passt, hängt vor allem davon ab, ob das Ergebnis im laufenden Vorgang gebraucht wird. Eine Kasse, die vor dem Bezahlen prüft, ob ein Gutscheincode gültig ist, braucht die synchrone Antwort – ohne Ergebnis kann sie nicht weiterarbeiten. Eine Stadtbibliothek, die einmal im Monat 50.000 Ausleihdatensätze an ein Statistiksystem meldet, übergibt sie besser als Job: Ob das Ergebnis eine Stunde später vorliegt, spielt keine Rolle, und ein kurzer Ausfall des Statistiksystems bremst die Bibliothek nicht aus.

Message Broker, Warteschlangen und Zustellgarantien

Ein Message Broker (z. B. ein MQTT-Broker, RabbitMQ oder Apache Kafka) sitzt zwischen Sendern und Empfängern. Er entkoppelt sie zeitlich (der Empfänger darf kurz offline sein), räumlich (Sender kennen die Empfänger nicht) und in der Last (Spitzen werden gepuffert). Er kann Nachrichten speichern, priorisieren und an mehrere Empfänger verteilen.

Wie oft eine Nachricht zugestellt wird, beschreibt die Zustellgarantie:

• höchstens einmal (at most once): Senden ohne Bestätigung. Schnell, aber Nachrichten können verloren gehen (MQTT QoS 0).

• mindestens einmal (at least once): Der Sender wiederholt, bis eine Bestätigung kommt. Nichts geht verloren, aber Nachrichten können doppelt ankommen (MQTT QoS 1).

• genau einmal (exactly once): zusätzlicher Abgleich, aufwendig (MQTT QoS 2).

Weil „mindestens einmal“ in der Praxis am häufigsten ist, sollte ein Empfänger idempotent arbeiten: Dieselbe Nachricht zweimal zu verarbeiten, darf kein anderes Ergebnis haben als einmal. Dafür bekommt jede Nachricht eine eindeutige ID (z. B. Auftragsnummer plus Sequenznummer bzw. ein Idempotenzschlüssel); der Empfänger merkt sich verarbeitete IDs und ignoriert Wiederholungen. Sonst entsteht aus einer wiederholten Bestellung ein zweiter Fertigungsauftrag.

Das Sequenzdiagramm zeigt den Ablauf an einer Lagerbuchung: Die Bestätigung geht verloren, die Buchung kommt ein zweites Mal an, und die Lagerverwaltung erkennt sie an ihrer ID.

Fehlerquellen bei der Übertragung und Gegenmaßnahmen

Die Tabelle fasst zusammen, was einer Nachricht auf ihrem Weg passieren kann – zuerst unterwegs, dann beim Empfänger, zuletzt an der Quelle.

Was passiert?	Gegenmaßnahme
Daten werden unterwegs verfälscht	Prüfsumme (z. B. CRC) bzw. Hashwert mitsenden und beim Empfänger prüfen; fehlerhafte Nachrichten verwerfen und neu anfordern
Nachricht geht verloren	Bestätigung (ACK), Wiederholung nach Timeout, Sequenznummern zum Erkennen von Lücken
Nachricht kommt doppelt an	eindeutige Nachrichten-ID bzw. Idempotenzschlüssel, idempotente Verarbeitung
Nachrichten kommen in vertauschter Reihenfolge an	Sequenznummer, Versionszähler, Broker-Partition je Schlüssel, Zeitstempel der Erzeugung
Daten werden mitgelesen	Transportverschlüsselung (TLS, VPN/IPsec)
Nachrichten werden gefälscht oder unterwegs verändert	Sender authentifizieren (Zertifikat, Token), Nachrichten signieren bzw. mit HMAC sichern
Empfänger ist nicht erreichbar (Wartung, Ausfall)	Puffer beim Sender (store and forward), Wiederholung mit wachsenden Abständen, Warteschlange bzw. Broker dazwischen; beim Empfänger Redundanz (Cluster)
Quelle ist überlastet und sendet verspätet	Übertragung priorisieren, Aufgaben entzerren, Vorverarbeitung an der Quelle (Edge Computing) begrenzen
Quelle liefert falsche Werte (Sensor defekt oder driftet)	Plausibilitätsprüfung (Grenzen, Sprünge), redundante Sensoren, regelmäßige Kalibrierung, Heartbeat gegen stillen Ausfall

Typische Fehler

• Push und Pull über die Datenrichtung erklären. Beide Verfahren transportieren die Daten von der Quelle zum Empfänger. Der Unterschied liegt darin, wer die Übertragung auslöst.

• „Asynchron“ mit „ohne Antwort, also unzuverlässig“ gleichsetzen. Asynchrone Kommunikation kann sehr zuverlässig sein (Broker mit Bestätigung). Sie garantiert nur keine Reihenfolge und keine sofortige Rückmeldung.

• Nur „Netzwerkprobleme“ als Ursache nennen. Das Netz liefert meist nur den Anlass. Entscheidend ist, dass asynchrone Nachrichten unabhängig voneinander laufen und niemand auf ihre Reihenfolge achtet – deshalb hilft auch kein besseres Netz, sondern nur eine Maßnahme beim Empfänger oder im Protokoll (z. B. Sequenznummern).

• Beim ereignisgesteuerten Senden den stillen Ausfall vergessen. Ohne Heartbeat ist „kein Alarm“ nicht von „Sensor tot“ zu unterscheiden.

• Daten löschen, bevor die Übertragung bestätigt ist. Erst nach der Bestätigung darf die Quelle ihren Puffer freigeben.

Leitfragen

1. Was legt eine Schnittstelle zwischen zwei Systemen fest? Antwort

Protokoll und Transportweg, Datenformat, Ablauf (wer beginnt, wann wird gesendet, wird auf Antwort gewartet) und Fehlerverhalten (Ausfall, Verlust, Doppelung). siehe Abschnitt „Was eine Schnittstelle festlegt“

2. Worin unterscheiden sich Push und Pull? Antwort

Beim Push sendet die Datenquelle auf eigene Initiative, sobald Daten vorliegen; beim Pull sendet sie nur auf Anforderung des Empfängers. Push ist aktueller und erzeugt weniger Netzlast, Pull lässt den Empfänger Zeitpunkt und Last bestimmen und braucht kein von außen erreichbares Ziel. siehe Abschnitt „Push und Pull“

3. Warum erzeugt Polling viel Last, und welche Push-Techniken ersetzen es? Antwort

Die meisten Abfragen liefern nichts Neues, trotzdem wird jede beantwortet; Änderungen fallen erst beim nächsten Intervall auf. Ersatz: Webhook, Server-Sent Events/WebSockets, Publish/Subscribe über einen Broker (MQTT). siehe Abschnitt „Polling“

4. Welche Risiken haben zyklische und ereignisgesteuerte Übertragung? Antwort

Zyklisch: Grenzwerte werden bis zu ein Intervall zu spät erkannt, bei einem Übertragungsfehler fehlen die Daten eines Intervalls, wenn sie vorher gelöscht werden. Ereignisgesteuert: Ein Ausfall der Quelle bleibt unbemerkt (stiller Ausfall), ein verlorener Alarm wird nie erkannt. Abhilfe: Heartbeat, Bestätigung und Wiederholung, Kombination beider Verfahren. siehe Abschnitt „Zyklisch oder ereignisgesteuert“

5. Wie kann es passieren, dass asynchron gesendete Nachrichten vertauscht verarbeitet werden? Antwort

Der Sender wartet nicht auf eine Bestätigung, die Nachrichten werden unabhängig übertragen. Unterschiedliche Laufzeiten, Wiederholungen nach Verlust, parallele Verarbeitung oder Priorisierung lassen eine spätere Nachricht die frühere überholen. siehe Abschnitt „Warum asynchrone Nachrichten sich überholen“

6. Wie lässt sich die Verarbeitungsreihenfolge sichern? Antwort

Sequenznummern je Quelle auswerten, Versionszähler am Datensatz (nur Änderungen auf dem aktuellen Stand übernehmen), Nachrichten mit gleichem Schlüssel über dieselbe Broker-Partition schicken, nach dem Zeitstempel der Erzeugung statt nach der Ankunft ordnen oder synchron senden (nächste Nachricht erst nach Bestätigung). siehe Abschnitt „Die Reihenfolge sichern“

7. Wann ist eine job-orientierte Schnittstelle einer synchronen überlegen? Antwort

Wenn das Ergebnis nicht im laufenden Vorgang gebraucht wird, viele Datensätze gebündelt werden sollen oder Lastspitzen zu erwarten sind: Der Job wird angenommen, wartet in der Warteschlange und wird vom Anbieter abgearbeitet. Braucht der Vorgang das Ergebnis sofort, ist die synchrone Schnittstelle besser. siehe Abschnitt „Synchrone und job-orientierte Schnittstellen“

8. Warum sollte ein Empfänger bei „mindestens einmal“-Zustellung idempotent arbeiten? Antwort

Weil Nachrichten nach einer Wiederholung doppelt ankommen können. Mit einer eindeutigen Nachrichten-ID erkennt der Empfänger Wiederholungen und verarbeitet sie nicht ein zweites Mal (z. B. kein doppelter Fertigungsauftrag). siehe Abschnitt „Message Broker, Warteschlangen und Zustellgarantien“

Links und weitere Informationen

• Übungen: Übungsaufgaben zu Schnittstellen und Übertragungsverfahren

• Voraussetzung: REST-API und HTTP, UML-Sequenzdiagramm

• weiterführend: MQTT: Publish/Subscribe, Topics, Wildcards und QoS, Industrielle Kommunikation, Datenaustauschformate CSV, XML und JSON, Edge und Fog Computing

• als Nachschlagewerk: RFC 9110 – HTTP Semantics (u. a. 202 Accepted), OASIS MQTT 5.0 – Quality of Service, W3C WebSub (Publish/Subscribe über HTTP-Webhooks)

---

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Schnittstellen und Übertragungsverfahren: Push und Pull, synchron und asynchron” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/schnittstellen-uebertragungsverfahren veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/software-entwurf/web-schnittstellen. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 29.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]