Exécuter les scénarios HTTP

Une route peut sembler correcte dans le code tout en renvoyant un statut inattendu, un JSON incomplet ou une erreur différente de celle prévue. Avant de connecter un front, vous pouvez envoyer directement des requêtes HTTP à votre API et observer ce qu’elle retourne.

Dans cette leçon, vous allez tester les lectures des commandes et des produits, créer une commande, puis vérifier un filtrage et une requête invalide. Vous utiliserez curl, disponible dans de nombreux environnements, ou vous pourrez reproduire les mêmes méthodes, URL, en-têtes et corps dans un client HTTP graphique.

Démarrer l’API et préparer le client

Démarrez le serveur avec la commande prévue par votre package.json, puis gardez son terminal ouvert. Les exemples supposent qu’il écoute sur le port 3000 et que les routeurs sont montés sous /api/commandes et /api/produits, conformément au contrat établi dans les leçons précédentes.

curl -i http://localhost:3000/api/commandes

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{"donnees":[...],"erreur":null}

L’option -i affiche les en-têtes avec le corps. Vérifiez que le statut indique une réponse de succès, que le type de contenu correspond à du JSON et que le corps respecte l’enveloppe du projet : une propriété donnees et une propriété erreur. Les points de suspension représentent les commandes présentes dans votre jeu de données en mémoire, pas une valeur à copier littéralement.

curl -i http://localhost:3000/api/produits

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{"donnees":[...],"erreur":null}

Cette seconde lecture permet de vérifier que la ressource produits répond indépendamment de la ressource commandes. Dans un client graphique, choisissez la méthode GET, saisissez l’URL et envoyez la requête ; inspectez ensuite séparément le statut, les en-têtes et le corps JSON.

Créer une commande

Pour une création, envoyez une requête POST à la collection des commandes avec un corps JSON conforme aux champs requis par votre middleware de validation. L’exemple utilise un produitId existant dans le jeu de données ; adaptez sa valeur si vos identifiants diffèrent, et conservez les noms de champs définis par votre contrôleur et votre service.

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

HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8

{"donnees":{"id":...},"erreur":null}

Le statut attendu pour une création réussie est 201 Created. Vérifiez aussi que donnees contient la commande créée et qu’erreur vaut null ; si votre service attribue un identifiant, relevez-le pour vos essais suivants. Le contenu exact dépend du modèle de commande défini dans le projet.

Tester un filtre et un cas invalide

Les filtres de commandes sont transmis dans l’URL sous forme de paramètres de requête, comme expliqué dans « Ajouter des filtres aux listes ». Choisissez une valeur de statut présente dans vos données et un identifiant de produit existant ; les critères sont combinés par le service et la réponse doit contenir uniquement les commandes qui satisfont les filtres fournis.

curl -i 'http://localhost:3000/api/commandes?statut=en-attente&produitId=1'

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8

{"donnees":[...],"erreur":null}

Les apostrophes autour de l’URL empêchent le terminal d’interpréter le caractère & comme une séparation de commandes. Si le tableau retourné est vide, vérifiez d’abord que vos données contiennent une commande correspondant simultanément au statut et au produit choisis, puis contrôlez les noms de paramètres lus par le contrôleur.

curl -i -X POST http://localhost:3000/api/commandes \
  -H 'Content-Type: application/json' \
  -d '{"quantite":"deux"}'

Réponse d’erreur JSON normalisée, avec un statut d’erreur et une propriété erreur renseignée. Le statut précis dépend de la règle de validation configurée.

Ce scénario négatif vérifie que la validation interrompt le traitement avant la création. Le statut précis dépend du code configuré pour cette erreur ; dans tous les cas, confirmez que la réponse ne prétend pas avoir créé une commande et que le message d’erreur est présent dans l’enveloppe JSON.

À retenir

• Démarrez l’API avant d’envoyer les requêtes et ciblez les URL des ressources montées par le serveur.
• Pour chaque réponse, vérifiez le statut HTTP, le type de contenu et le corps JSON normalisé.
• Testez une lecture et une création valides, puis un filtrage avec des valeurs présentes dans le jeu de données.
• Ajoutez un cas invalide pour confirmer que la requête est refusée et qu’une erreur JSON est renvoyée.

Dans la leçon suivante, vous contrôlerez le parcours complet d’une requête et la cohérence du flux d’erreurs dans le projet.