Validation et gestion des erreurs

Une API se juge à ses réponses d'échec bien plus qu'à ses réponses de succès. Le chemin nominal est facile : il a été écrit en premier, testé en premier, démontré en premier. Les erreurs, elles, arrivent en production, chez un client que vous ne connaissez pas, dans une situation que personne n'avait prévue — et c'est à ce moment-là que la qualité de l'API se révèle.

Le symptôme classique est un catalogue d'incohérences. Un identifiant inexistant renvoie 500 avec une page HTML d'erreur Spring. Un champ obligatoire manquant renvoie 400 avec une structure Spring par défaut illisible. Un conflit métier renvoie 200 avec {"succes": false}. Un développeur pressé ajoute try/catch dans un contrôleur, un autre ajoute @ResponseStatus sur une exception, un troisième renvoie une Map. Six mois plus tard, l'équipe cliente a écrit du code différent pour chaque endpoint, et personne n'ose plus rien changer.

La sortie de cette impasse tient en deux décisions. D'abord, valider les entrées au bord de l'application, de façon déclarative, pour qu'aucune donnée douteuse n'atteigne le service. Ensuite, centraliser la traduction des exceptions en réponses HTTP en un seul endroit, avec un format unique. Spring 6 fournit ce format : ProblemDetail, l'implémentation de la RFC 9457.