# 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

- [x] 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
- [x] 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
- [x] `InfoServer` um detaillierte Statusinformationen erweitern
  - Senderverbindungen · Health-Checks · letzte Befehle / Pings
  - → bereits in ToDo 2 angelegt; ergänzt um Top-Level `health`-Summary + `generatedAt`
- [x] API-Endpunkte klar dokumentieren
  - `/api/status` · `/api/position`
  - → `doc/API.md`
- [x] 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.