Codes d'erreur
Format et codes HTTP retournés par l'API
L'API retourne des codes HTTP standards avec un corps au format problem+json (RFC 7807).
Format des erreurs
{
"type": "...",
"title": "...",
"status": 400,
"detail": "Explication détaillée",
"instance": "/properties?..."
}Champs (via le schéma Error de l'OpenAPI) :
| Champ | Type | Description |
|---|---|---|
type | string | URI identifiant le type d'erreur |
title | string | null | Résumé court |
status | number | Code HTTP |
detail | string | null | Description détaillée |
instance | string | null | URI de la requête fautive |
422 Validation (ConstraintViolation)
Les erreurs de validation utilisent le schéma ConstraintViolation (toujours problem+json). Le message de validation est porté par le champ detail (préfixé par le chemin du champ fautif) ; il n'y a pas de tableau violations séparé :
{
"type": "/validation_errors/c1051bb4-d103-4f74-8988-acbcafc7fdc3",
"title": "Validation Failed",
"status": 422,
"detail": "name: This value should not be blank.",
"instance": "/alerts"
}Codes documentés par endpoint
Les endpoints de l'OpenAPI exposent les codes suivants selon le contexte :
| Code | Usage |
|---|---|
200 | Succès (lecture) |
201 | Ressource créée |
204 | Succès sans contenu (DELETE) |
400 | Requête invalide (paramètre mal formé) |
403 | Accès refusé |
404 | Ressource introuvable |
422 | Échec de validation — message dans detail |
Le 429 Too Many Requests n'est pas déclaré sur les réponses individuelles des endpoints OpenAPI : il est appliqué globalement par le rate-limiter en amont (voir Rate limits). Considérez-le donc comme une réponse possible sur n'importe quelle route, en plus des codes du tableau ci-dessus.