# 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