Fabian Wolter
2.3 KiB
017 - Serverstruktur: Status-API ausgelagert
Ziel
Die Status-API wurde aus Main.kt ausgelagert, damit der Ktor-Server modularer aufgebaut ist.
Ausgangslage
Vor diesem Schritt enthielt Main.kt mehrere Verantwortlichkeiten:
- Serverstart
- ContentNegotiation-Konfiguration
- Routing
- Status-DTOs
- Status-Endpunkte
- Datenbankstatus-Mapping
Das war für den frühen Prototypen okay, wird aber bei wachsender API-Struktur unübersichtlich.
Änderung
Es wurde ein neues API-Package angelegt:
src/main/kotlin/de/ruvnox/tactical/api
Neue Dateien:
- StatusDtos.kt
- StatusRoutes.kt
Geänderte Datei:
- Main.kt
StatusDtos.kt
Diese Datei enthält die serialisierbaren Antwortmodelle für den Status-Endpunkt:
- ServiceStatusResponse
- DatabaseStatusResponse
Die DTOs sind mit kotlinx.serialization Serializable annotiert.
StatusRoutes.kt
Diese Datei enthält die Status-Routen:
- GET /
- GET /health
- GET /api/v1/status
Der Datenbankstatus wird über Database.check() abgefragt und in DatabaseStatusResponse gemappt.
Main.kt nach Refactor
Main.kt enthält jetzt nur noch:
- Lesen von SERVER_HOST
- Lesen von SERVER_PORT
- Start des Netty-Servers
- Installation von ContentNegotiation
- Registrierung der Status-Routen über statusRoutes()
API-Verhalten
Die Endpunkte bleiben unverändert erreichbar.
Lokal:
curl -fsS http://127.0.0.1:8080/ curl -fsS http://127.0.0.1:8080/health curl -fsS http://127.0.0.1:8080/api/v1/status
Öffentlich:
curl -fsS https://tactical.ruvnox.de/api/v1/status
Erwartete Statusantwort
/api/v1/status liefert weiterhin:
- service
- status
- version
- database.status
- database.host
- database.port
- database.name
- database.latencyMs
Deployment
Das Deployment wurde über das bestehende Script ausgeführt:
/opt/ruvnox/tactical/scripts/deploy-server.sh
Erwartetes Ergebnis:
Deployment erfolgreich.
Git-Commit
tactical-server:
Extract status API routes
Abschlussstand
- Status-DTOs ausgelagert
- Status-Routen ausgelagert
- Main.kt vereinfacht
- Build erfolgreich
- Deployment erfolgreich
- API lokal geprüft
- API öffentlich geprüft
- Server-Code committed und gepusht
Nächster Abschnitt
Als nächstes kann die echte Repository-Schicht vorbereitet werden:
- UserRepository
- OperationRoomRepository
- AuditEventRepository
- DB-Zugriffsfunktionen für die ersten API-Routen