Johan LEROY
344f82fcdd
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.
24 lines
592 B
Python
24 lines
592 B
Python
# Piège : ces modèles ne décrivent rien, ils publient. Ce sont eux que Swagger montre, donc ils
|
|
# doivent suivre `validation_error_handler()` et `unhandled_error_handler()` d'`app/api/errors.py`
|
|
# à la lettre. Un champ renommé là-bas sans l'être ici rend la documentation fausse en silence.
|
|
|
|
from pydantic import BaseModel
|
|
|
|
|
|
class ErrorResponse(BaseModel):
|
|
detail: str
|
|
|
|
|
|
class FieldError(BaseModel):
|
|
champ: str
|
|
type: str
|
|
|
|
|
|
class ValidationErrorResponse(BaseModel):
|
|
detail: list[FieldError]
|
|
|
|
|
|
class InternalErrorResponse(BaseModel):
|
|
detail: str
|
|
correlation: str
|