appRobotDriver/doc/ToDo_5_API.md

ToDo 5 — API und Antwortlogik

Ziel der Verbesserung

Die Schnittstellen sollen klar und vorhersagbar antworten. Steuerbefehle brauchen eigene Antwortpfade, und Status-/Positionsergebnisse müssen eindeutig getrennt werden.

Aufgaben

• WebSocket-Antwortlogik strukturieren
  • Steuerbefehle erhalten gezielte Responses
  • Ping, M114, Statusabfragen und Fehlermeldungen getrennt behandeln
  • → server/InputWS.js als klarer Router; Ping/M114 antworten gezielt an den Anfrager
• Broadcasts nur dort verwenden, wo sie sinnvoll sind
  • Broadcasts für Status-Updates, nicht für direkte Steuerantworten
  • → Bewegung (G-Code) broadcastet die neue Position; Ping/M114 sind gezielt
• InfoServer um detaillierte Statusinformationen erweitern
  • Senderverbindungen · Health-Checks · letzte Befehle / Pings
  • → bereits in ToDo 2 angelegt; ergänzt um Top-Level health-Summary + generatedAt
• API-Endpunkte klar dokumentieren
  • /api/status · /api/position
  • → doc/API.md
• Fehlermeldungen konsistent und maschinenlesbar machen
  • → einheitliches Fehler-Envelope { type, code, message, input } (UNKNOWN_COMMAND / GCODE_ERROR / FILE_ERROR)

Tests

• test/InputWS.api.test.js — gezielte vs. Broadcast-Antworten, Fehler-Envelope
• test/InfoServer.test.js — Health-Summary + generatedAt

Bewusst nicht in diesem ToDo

• Feinere Zielsteuerung der Datei-Befehle (z. B. FShow nur an Anfrager) und FFirst/FLast → gehören zur Datei-Verwaltung in ToDo 4.
• Erfolgs-Payloads (Ping, Positions-JSON) bleiben aus Rückwärtskompatibilität im Rohformat (externe Clients: Simulation/Gamepad); nur Fehler nutzen das Envelope.