fiber-rest-api

# Fiber REST API Patterns ## Overview A Fiber handler is a translator: HTTP in → service call → HTTP out. Business logic never lives there. The recurring defects are fat handlers, per-handler error mapping that drifts, and endpoints that quietly drop the auth middleware their neighbors have. **Core principle:** Handlers parse, validate, delegate, and map. Nothing else. ## Rules - `github.com/gofiber/fiber/v2` with the Goccy JSON encoder. - **Thin handlers:** parse/validate input → call the application service → map result to response DTO. No business logic, no SQL, no cross-entity rules in the handler. - **Explicit DTO structs** aligned with domain types — never `map[string]any`. Annotate every handler for Swagger. - **Validate and bound all input at the boundary:** lengths, ranges, enum values, UUID parsing. Reject early with 400 and a field-specific message. - **Map domain errors to status in ONE place** (a shared error handler / mapper), not per handler, so the mapping can't drift. - **One error JSON shape** across the API; message actionable for the caller, internal detail to logs. - **New endpoints get the SAME middleware chain** (auth, logging, request-id) as their neighbors — copy the adjacent route's wiring, don't invent one. ## Status codes | Code | When | |------|------| | 200 / 201 | success / created | | 400 | validation / malformed input | | 401 / 403 | unauthenticated / forbidden | | 404 | resource missing | | 409 | conflict (duplicate, invalid transition...