Document extracted status API routes
This commit is contained in:
@@ -17,3 +17,5 @@
|
||||
- [015 - Initiales PostgreSQL-Datenbankschema und Migrationen](015-initiales-postgresql-datenbankschema-und-migrationen.md)
|
||||
|
||||
- [016 - Datenbank-Healthcheck ausgelagert](016-datenbank-healthcheck-ausgelagert.md)
|
||||
|
||||
- [017 - Serverstruktur: Status-API ausgelagert](017-serverstruktur-status-api-ausgelagert.md)
|
||||
|
||||
@@ -0,0 +1,125 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user