RESTful-API-Design und WebSocket-Integration

REST bildet CRUD auf HTTP ab: GET zum Lesen, POST zum Erstellen, PATCH für partielle Updates, DELETE zum Entfernen. Nutze Statuscodes ehrlich — 200 mit einem Fehler-JSON bricht Clients.

Versioniere im Pfad (/v1/), paginiere große Listen (Cursor-Feeds für Append-only-Streams), und dokumentiere Breaking Changes mit einem Deprecation-Fenster.

API-Keys identifizieren; Secrets beweisen. Für Trading-Endpunkte signiere per HMAC einen kanonischen String (Methode + Pfad + Body + Zeitstempel), damit das Secret nie über die Leitung geht. Lehne veraltete Zeitstempel ab, um Replays zu blockieren — ±30s ist ein gängiges Fenster.

OAuth passt für Drittanbieter-Apps; reine Börsen-Bots bleiben oft bei Key+HMAC. Rate Limits: erwarte 429 und beachte Retry-After.

Die Sitzung startet als HTTP-GET mit Upgrade: websocket; der Server antwortet mit 101 Switching Protocols. Danach sind Frames günstig im Vergleich zu wiederholten TLS-Handshakes bei HTTP-Polling.

Subscribe-Nachrichten sind meist JSON: Methode, Kanäle und manchmal Auth-Signaturen für private Fills.

Der Trades-Stream sind Tick-Daten; Orderbücher sind Snapshot + Delta mit Sequenznummern. Verpasst du Sequenzen, synchronisiere über ein REST-Snapshot neu und wende dann Deltas mit Sequenz > Snapshot an.

Heartbeat: sende Ping oder erwarte Server-Pings; verbinde mit gejittertem Backoff neu, um Thundering Herds zu vermeiden.

GraphQL reduziert Over-Fetching für Dashboards; viele Börsen setzen für Trading-Hotpaths weiterhin auf REST. OpenAPI-Spezifikationen (Swagger) helfen bei Codegen und QA — halte Beispiele copy-pasteable.

Lass die WebSocket-Loop in einem Task laufen, schreibe die letzten Preise in eine Thread-sichere Map, exponiere HTTP für Health-Checks. Protokolliere Reconnect-Zähler; alarmiere, wenn sie ansteigen.