Finaliser et contrôler le flux d’erreurs

Une API peut répondre correctement aux requêtes courantes tout en laissant passer une entrée invalide ou en renvoyant une erreur dans un format différent des autres. Avant de brancher un client, vous devez contrôler le parcours complet : la route sélectionne les middlewares et le contrôleur, le contrôleur appelle le service, puis la réponse ou l’erreur revient au client sous une forme prévisible.

Vous avez déjà testé des requêtes HTTP positives et négatives dans la leçon précédente. Ici, vous réutilisez ces scénarios pour vérifier leur cohérence avec l’organisation du projet et repérer à quel étage une anomalie se produit, sans modifier le jeu de données ni ajouter de nouvelle route.

1. Suivre le trajet d’une requête

Commencez par lire `serveur.js`, puis les fichiers de routes, de contrôleurs, de services et de middlewares déjà présents. Dans le serveur, vérifiez que le décodage JSON et les routeurs sont configurés avant le middleware central d’erreurs, lequel doit rester le dernier middleware applicatif. Les routeurs doivent être montés sur les préfixes prévus par le contrat, et chaque route doit associer les validations requises avant le contrôleur concerné.

Pour une création de commande, le trajet attendu est le suivant : la requête arrive sur la route POST, le middleware vérifie son corps, puis le contrôleur délègue la création au service et construit la réponse. Si la validation échoue, le contrôleur et le service ne doivent pas être appelés ; l’erreur est transmise au gestionnaire central, qui produit l’enveloppe JSON d’erreur convenue. Pour une lecture filtrée, vérifiez de la même manière que le contrôleur transmet les critères au service et que le service retourne les résultats sans prendre en charge le format HTTP.

2. Contrôler les cas HTTP représentatifs

Démarrez le serveur comme dans la leçon d’initialisation, puis envoyez les requêtes depuis un terminal. Les exemples ci-dessous supposent le port 3000 et les chemins documentés pour le projet ; adaptez uniquement l’hôte si vous avez configuré un autre port. La première requête vérifie une liste filtrée, la deuxième vérifie une création valide, et la troisième contrôle le rejet d’un corps incomplet.

curl -i 'http://localhost:3000/api/commandes?statut=en-attente'
curl -i -X POST 'http://localhost:3000/api/commandes' \
  -H 'Content-Type: application/json' \
  -d '{"produitId":1,"quantite":2}'
curl -i -X POST 'http://localhost:3000/api/commandes' \
  -H 'Content-Type: application/json' \
  -d '{"quantite":"deux"}'

La première réponse doit contenir une liste dans `donnees` et `null` dans `erreur`. La création valide doit renvoyer la commande créée dans `donnees`, avec le statut de succès prévu par le contrat. Le corps invalide doit produire une erreur de validation dans `erreur`, sans créer de commande.

Comparez le statut HTTP, le type de contenu et le corps de chacune des réponses. Les réponses de succès comme les réponses d’erreur doivent respecter l’enveloppe `{ "donnees": ..., "erreur": ... }` ; dans une erreur, `donnees` vaut `null` et `erreur` expose un code et un message. Vérifiez aussi que le test invalide n’a pas modifié les données : relancez la liste ou la lecture pertinente et assurez-vous qu’aucune commande n’a été ajoutée.

3. Localiser une incohérence

Si une réponse invalide n’a pas le format attendu, suivez le trajet dans l’ordre. Vérifiez d’abord que la route applique le middleware voulu, puis que celui-ci appelle `next` avec une erreur plutôt que de poursuivre vers le contrôleur. Contrôlez ensuite que les erreurs asynchrones sont transmises à Express et que le middleware central est bien monté après les routes ; une réponse HTML ou une erreur non normalisée peut indiquer que le flux n’atteint pas ce gestionnaire.

Si la validation répond correctement mais que la création échoue, vérifiez le passage des données entre contrôleur et service, puis les références utilisées par le jeu de données en mémoire. Si une requête de liste ignore un filtre, examinez la lecture du paramètre dans le contrôleur et son application dans le service ; ne déplacez pas le filtrage dans la route. Cette méthode vous aide à corriger l’étage responsable sans disperser la logique métier ni la gestion HTTP.

À retenir

• Vérifiez l’ordre des middlewares et le montage des routeurs dans `serveur.js`.
• Suivez chaque requête de la route au contrôleur et au service, puis jusqu’à la réponse.
• Un échec de validation doit interrompre le traitement avant le contrôleur et le service.
• Toutes les erreurs doivent atteindre le gestionnaire central et conserver l’enveloppe JSON convenue.
• Utilisez les tests HTTP et les données du projet pour confirmer qu’une requête refusée ne modifie pas l’état.

Vous disposez maintenant d’une procédure de contrôle pour vérifier la cohérence de l’API avant de la connecter à un client.