Fabian Wolter
126 lines
2.3 KiB
Markdown
126 lines
2.3 KiB
Markdown
# 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
|