36 lines
1.7 KiB
Markdown
36 lines
1.7 KiB
Markdown
# 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. |