Déploiement
Déploiement • Chapitre 6 : Déploiement d'une API REST

Test des routes après le déploiement

Validez la fiabilité de votre API déployée : tests de santé en ligne de commande avec curl, vérification des codes de statut HTTP, tests de sécurité des routes protégées et automatisation Postman.

🧪
Outil curl

Inspection précise des en-têtes de réponse et des temps de latence sans passer par le navigateur.

🛡️
Contrôle 401 & 403

Vérification que les endpoints confidentiels rejettent bien les requêtes sans jeton valide.

📮
Runner Postman

Exécution automatisée de suites de tests de validation d'API avant ouverture aux clients.

⏱️
Audit de Latence

Mesure du temps de premier octet (TTFB) pour identifier les requêtes lentes.

curl-api-verification.sh
# 1. Tester la route publique de santé (Health check)
$ curl -i https://api.mon-site.com/api/v1/health
HTTP/2 200 
content-type: application/json; charset=utf-8
strict-transport-security: max-age=31536000
x-content-type-options: nosniff

{"status":"UP","timestamp":"2026-10-11T12:55:00.000Z"}

# 2. Vérifier que la route protégée bloque les requêtes non autorisées (401)
$ curl -i https://api.mon-site.com/api/v1/admin/users
HTTP/2 401 
content-type: application/json; charset=utf-8

{"error":"Token d'authentification manquant ou expiré."}

# 3. Tester une requête authentifiée avec un jeton Bearer JWT
$ curl -s -X GET https://api.mon-site.com/api/v1/admin/users      -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6..."      -H "Accept: application/json" | jq .total
42

Guide Approfondi & Architecture Système

1. Pourquoi tester avec 'curl' plutôt qu'avec le navigateur ?

Le navigateur applique des mécanismes de cache, injecte des cookies implicites et masque les détails réseau. Avec curl -i dans votre terminal :
  • Vous lisez les en-têtes HTTP bruts (Content-Type, Cache-Control, CORS).
  • Vous validez le comportement exact d'un client mobile ou d'une autre machine.
  • Vous pouvez automatiser ces tests dans un script bash de déploiement continu.

2. Les 4 Tests Obligatoires après chaque Mise en Ligne

Avant de déclarer votre déploiement réussi, suivez ce protocole :
  1. Le Test du Ping : La route /health répond-elle 200 en moins de 100 ms ?
  2. Le Test du Verrou : Une tentative d'accès sans token à une route privée renvoie-t-elle bien 401 Unauthorized ?
  3. Le Test d'Écriture : Un POST crée-t-il bien un enregistrement en base de données et renvoie-t-il 201 Created ?
  4. Le Test de la Mauvaise Entrée : Un envoi de JSON invalide renvoie-t-il bien 400 Bad Request sans faire crasher l'API ?

Tableau de Diagnostic des Réponses HTTP lors des Tests d'API

Code ReçuSignification en ProductionAction Requise
200 / 201Succès : l'API fonctionne parfaitementAucune, déploiement validé
401 / 403Accès refusé ou permissions insuffisantesVérifier le format du header 'Authorization: Bearer <token>'
404 Not FoundEndpoint introuvableVérifier la casse de l'URL et la directive proxy_pass de Nginx
502 Bad GatewayNginx n'arrive pas à joindre Node.jsVérifier que le processus tourne (pm2 status mon-api)
500 Internal ErrorCrash dans le code de l'APIConsulter immédiatement les logs (pm2 logs mon-api)