Le schéma ne déclarait aucun code d'erreur : ni 401, ni 403, ni 404, ni 409,
ni 429. Swagger affirmait que /auth/login ne pouvait répondre que 200 ou 422,
alors que 31-contrat-authentification.md décrit ces codes comme le contrat que
le frontend doit traiter.
Le 422 publié était pire qu'absent : le schéma exposait HTTPValidationError,
le modèle par défaut de FastAPI avec sa clé `loc`, quand
validation_error_handler renvoie {"detail": [{"champ", "type"}]}. Un client
codé sur la documentation lisait une clé qui n'arrive jamais.
Les métadonnées arrivent avec : description, résumé et une description par
tag. `servers`, `license_info` et `contact` restent absents, ils poseraient
des décisions qui ne sont pas prises.
Le cookie de rafraîchissement devient visible par un APIKeyCookie en
auto_error=False, purement documentaire : lit_le_cookie() reste seul maître du
401 de /auth/refresh.
Au passage, health.py posait son tag deux fois, une fois sur son APIRouter et
une fois à l'include_router.
10 lines
440 B
Python
10 lines
440 B
Python
from fastapi import APIRouter
|
|
|
|
from app.api.openapi import REPONSE_SERVEUR, REPONSES_ADMIN
|
|
from app.api.v1.endpoints import auth, health, users
|
|
|
|
api_router = APIRouter(responses=REPONSE_SERVEUR)
|
|
api_router.include_router(health.router, prefix="/health", tags=["health"])
|
|
api_router.include_router(auth.router, prefix="/auth", tags=["auth"])
|
|
api_router.include_router(users.router, prefix="/users", tags=["users"], responses=REPONSES_ADMIN)
|