Jede Börsen-API bietet in der Regel beide Zugänge an: REST-Endpunkte, die auf Anfrage den aktuellen Stand liefern, und WebSocket-Streams, die Änderungen laufend zusenden. Beide transportieren dieselben Marktdaten — Ticker, Orderbuch, abgeschlossene Trades. Der Unterschied liegt nicht im Inhalt, sondern im Kommunikationsmuster: fragen oder abonnieren.
REST: Nachfragen im Takt
Beim Polling ruft der Bot in festen Abständen einen Endpunkt auf — etwa alle zehn Sekunden den aktuellen Kurs. Das Muster ist simpel und robust: Jede Antwort ist ein vollständiger, in sich konsistenter Stand. Fällt eine Anfrage aus, holt die nächste den aktuellen Zustand — es gibt keinen Verbindungszustand, den man verwalten müsste. Genau diese Zustandslosigkeit macht REST so fehlertolerant.
Die Grenzen des Pollings
- Latenz: Zwischen zwei Abfragen ist der Bot blind. Bei einem Intervall von zehn Sekunden sieht er eine Kursbewegung im Schnitt fünf Sekunden zu spät.
- Rate-Limits: Börsen begrenzen Anfragen pro Minute. Wer schneller pollt oder viele Märkte beobachtet, läuft ins Limit — und wird gedrosselt oder gesperrt.
- Verschwendung: In ruhigen Märkten liefern die meisten Abfragen dieselbe Antwort wie zuvor. Der Bot bezahlt Aufwand für Information, die sich nicht geändert hat.
- Lückenhafte Sicht: Einzelne Trades zwischen zwei Abfragen bleiben unsichtbar — für Strategien, die auf Handelsaktivität reagieren, ein blinder Fleck.
WebSocket: der stehende Draht
Ein WebSocket ist eine dauerhaft offene Verbindung. Der Bot abonniert Kanäle — etwa Ticker oder Orderbuch eines Handelspaares — und der Server schiebt jede Änderung sofort hinüber, oft innerhalb von Millisekunden. Das löst die Polling-Probleme elegant: minimale Latenz, keine verschwendeten Anfragen, lückenlose Ereignisfolge. Der Preis dafür ist Zustand: Die Verbindung muss aufgebaut, überwacht und nach jedem Abriss korrekt wiederhergestellt werden. Ein Stream ist kein Selbstläufer, sondern ein Bauteil, das Pflege im Betrieb braucht.
Reconnect, Datenlücken und Heartbeats
Verbindungen reissen ab — durch Netzwerkprobleme, Serverwartung oder Timeouts. Entscheidend ist, was der Bot dann tut. Eine saubere Reconnect-Logik verbindet automatisch neu, mit wachsenden Wartezeiten zwischen den Versuchen, damit sie den Server nicht flutet. Das eigentliche Problem ist aber die Datenlücke: Alles, was während der Trennung passiert ist, hat der Stream nie geliefert. Ein Bot, der das ignoriert, arbeitet mit einem veralteten Orderbuch weiter. Die Standardlösung: nach jedem Reconnect den aktuellen Stand per REST-Snapshot nachladen und erst dann wieder auf den Stream vertrauen; wo die Börse Sequenznummern mitliefert, lassen sich fehlende Nachrichten sogar exakt erkennen. Heartbeats — regelmässige Lebenszeichen in beide Richtungen — decken den heimtückischsten Fall auf: die Verbindung, die offen aussieht, aber nichts mehr liefert.
Die gefährlichste Verbindung ist nicht die abgerissene, sondern die eingefrorene: Der Bot hält den letzten empfangenen Kurs für aktuell und entscheidet auf Basis einer Vergangenheit, die er für Gegenwart hält.
Wann REST völlig reicht
Die ehrliche Antwort: häufiger, als Technik-Begeisterung vermuten lässt. Ein DCA-Plan, der einmal täglich kauft, ein Rebalancing pro Woche, ein Signal-Check pro Stunde — für all das ist ein Stream Overkill. Wer nur alle paar Minuten oder seltener entscheidet, bekommt mit Polling dieselbe Datenqualität bei einem Bruchteil der Komplexität. WebSocket lohnt sich, wenn die Strategie tatsächlich auf Sekunden- oder Tick-Ebene reagiert, viele Märkte gleichzeitig beobachtet werden oder Rate-Limits das nötige Polling-Tempo verbieten. In der Praxis fahren viele Systeme zweigleisig: Stream für die Marktsicht, REST für Orders, Kontostand und die Snapshots nach jedem Reconnect.
Erst der Datenweg, dann die Strategie
Die beste Handelslogik ist wertlos, wenn ihre Eingangsdaten lückenhaft, verspätet oder eingefroren sind. Wer eine Automation plant, sollte den Datenweg wie ein eigenes Teilprojekt behandeln: Anforderungen der Strategie klären, das einfachste ausreichende Muster wählen und die Fehlerfälle — Abriss, Lücke, Stillstand — im Dry-Run gezielt durchspielen, bevor echtes Kapital von diesen Daten abhängt.