Skip to content

Chapitre 1.5 : Tester l'API avec Postman

Temps d'étude : 50 minutes

1. Pourquoi tester l'API ? Vérification avant le lancement

Imaginez : avant de lancer une fusée, les ingénieurs procèdent à des mises sous tension des systèmes pour test. Oubliez la vérification — et la mission pourrait échouer !

Le test d'API — c'est votre série de tests de contrôle :

  • ✅ Vérifier la fonctionnalité des "points d'amarrage"

  • 🛡️ Détecter les vulnérabilités avant l'utilisation opérationnelle

  • 📊 S'assurer que les données sont transmises sans distorsion

💡 Analogie spatiale : Postman — comme une console de test du Centre de Contrôle de Mission (CCM) pour simuler tous les scénarios : "Que se passe-t-il si je demande des données sur une planète inexistante ? Le serveur supportera-t-il 1000 requêtes/seconde ?"

2. Postman : "Centre de contrôle des missions" pour les API

Fonctionnalités :

  • 📡 Envoi de toute requête HTTP (GET, POST, PUT, DELETE)

  • 🔍 Analyse des réponses (codes de statut, en-têtes, corps JSON)

  • 🧪 Écriture de tests automatisés (JavaScript)

  • 🌐 Gestion des variables d'environnement (test vs production)

👉 Télécharger Postman

3. Premier lancement : Testons l'API des planètes

Étape 1 : Créer une requête

  1. Ouvrez Postman → New → Request

  2. Saisissez l'URL : https://api.spacexdata.com/v4/rockets

  3. Sélectionnez la méthode : GET

Étape 2 : Envoyer un "signal" 

[CCM] -- GET /planets --> [Serveur SpaceX]

Étape 3 : Analyser la télémétrie : - Statut : 200 OK - Corps de la réponse (JSON) : liste des fusées avec leurs paramètres 

[
  {
    "name": "Falcon 1",
    "type": "rocket",
    "active": false,
    "stages": 2,
    "id": "5e9d0d95eda69955f709d1eb"
  },
  {
    "name": "Falcon 9",
    "type": "rocket",
    "active": true,
    "id": "5e9d0d95eda69973a809d1ec"
  }
]

4. Schéma : Composants de Postman

[Espace de travail]
├── Onglet "Params" (Paramètres de requête)
├── Onglet "Headers" (En-têtes)
├── Onglet "Body" (Corps de la requête pour POST/PUT)
├── Onglet "Tests" (Scripts de vérification)
└── Panneau de réponse (Status, Time, Size, Body)

5. Créer un scénario complexe : Lancement de mission

Test : Ajout d'une nouvelle planète au catalogue

  1. Méthode : POST

  2. URL : https://jsonplaceholder.typicode.com/posts (exemple)

  3. Dans les Headers : 

     { "Content-Type": "application/json" }

  4. Dans le Body (raw → JSON) : 
    {
 "title": "New Exoplanet Found",
 "body": "Proxima Centauri b shows signs of a stable atmosphere.",
 "userId": 1
 }

Vérification automatisée dans les Tests : 

// Vérification du statut
pm.test("Post created successfully", () => {
    pm.response.to.have.status(201);
});

// Vérification de la structure et des données de la réponse
pm.test("Response contains the new post data", () => {
    const response = pm.response.json();
    pm.expect(response).to.have.property("id"); // On vérifie que le serveur a attribué un ID
    pm.expect(response.title).to.eql("New Exoplanet Found");
});

6. Variables d'environnement : Terre vs Mars

Comment tester sur différents serveurs (test/production) ?

  1. Créez des environnements :
  2. Local → http://localhost:3000

  3. Production → https://api.nasa.gov

  4. Dans les requêtes, utilisez des variables : 

    {{base_url}}/planets  # Substituera l'URL actuelle

⚠️ Important ! Ne testez jamais DELETE sur un serveur de production !

7. Collections : Bibliothèque de missions spatiales

Regroupez les requêtes : 

    📂 Collection "NASA"
    ├── GET Planètes
    ├── POST Nouvelle planète
    └── DELETE Planète (mode test)
Avantages :

  • 🚀 Lancement de tous les tests en un seul clic
  • 📤 Export/import de configurations
  • 👨‍🚀 Travail d'équipe collaboratif

8. Automatisation : Vérifications régulières des satellites

Configurez le monitoring d'API via Postman :

  1. Schedule → Toutes les 2 heures

  2. Tests : 

    pm.test("Спутник онлайн", () => {
  pm.response.to.have.status(200);
  pm.expect(pm.response.json().signal).above(50); // Signal >50%
});

  3. Notifications dans Slack/par e-mail en cas d'échec

Quiz de révision

1. Postman est utilisé pour :

2. Quel statut attendre lors de la création réussie d'un objet ?

3. Où écrire les tests automatisés dans Postman ?

4. Les variables d'environnement sont nécessaires pour :

5. Que vérifient les monitorings réguliers ?

🚀 Bilan du chapitre : Postman — votre "tableau de bord" universel pour tester les API. Avec lui, vous : - Vérifierez le fonctionnement des "systèmes de bord" avant le lancement - Créerez une bibliothèque de scénarios de test - Automatiserez la surveillance des services spatiaux

📌 Exercice pratique :

  1. Installez Postman
  2. Créez une requête vers l'API SpaceX : GET https://api.spacexdata.com/v4/launches/latest
  3. Écrivez un test vérifiant que :
  4. Le statut de la réponse est 200
  5. Le champ name contient le mot "Falcon"
  6. Le temps de réponse est < 500 ms

Félicitations pour avoir terminé le Chapitre 1 !

Vous avez maîtrisé les bases de l'utilisation des API. Dans les prochains chapitres, nous construirons notre propre "vaisseau spatial" — une application web utilisant les API spatiales !

🌌 Ressources supplémentaires :