DEV Community

Cover image for Les meilleurs outils CLI légers pour les tests d'API
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Les meilleurs outils CLI légers pour les tests d'API

La plupart des outils de test d’API imposent d’ouvrir une interface, de se connecter et de naviguer dans un espace de travail avant d’envoyer une requête. C’est utile pour découvrir une API, mais moins adapté au terminal : vous voulez lancer une commande, lire la réponse et continuer.

Essayez Apidog dès aujourd’hui

Un outil CLI « léger » privilégie une petite installation, un démarrage rapide, peu de configuration et une sortie exploitable avec jq, grep ou un pipeline CI. Ce critère est différent du nombre de fonctionnalités ou du statut open source. Pour une vue plus large incluant les interfaces graphiques, consultez les meilleurs outils de test d’API gratuits.

Voici huit outils CLI pour tester des API REST et HTTP, du client manuel minimaliste à l’exécuteur de scénarios pour la CI.

Qu’est-ce qui rend un outil CLI léger pour le test d’API ?

Pour cette sélection, un outil doit répondre à ces critères :

  • Encombrement réduit : binaire unique, installation pip/npm ou commande npx. Idéalement, aucun démon à configurer.
  • Démarrage rapide : l’outil lance la requête immédiatement, sans préchauffage d’un runtime lourd.
  • Configuration minimale : la première requête fonctionne sans compte, projet ou fichier de configuration.
  • Sortie adaptée au terminal : résultat lisible, facilement redirigeable, avec des codes de sortie exploitables en CI.

Si votre besoin est surtout d’appeler un endpoint à la main, consultez aussi les alternatives à curl pour les tests d’API REST.

curl : la référence déjà installée

curl est généralement déjà disponible sur macOS, Linux et les versions modernes de Windows. Il fonctionne dans les scripts, les conteneurs et les environnements verrouillés où vous ne pouvez rien installer.

# Vérifier la version installée
curl --version

# Envoyer un POST JSON et n'afficher que le statut HTTP
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"user":"acme","plan":"pro"}'
Enter fullscreen mode Exit fullscreen mode

Idéal pour : les requêtes ponctuelles, les scripts shell et les environnements sans installation possible.

Limite : les en-têtes, corps JSON et assertions sont à gérer manuellement. Pour tester une réponse, vous devrez généralement combiner curl avec jq et contrôler le code de sortie vous-même.

curl -s https://httpbin.org/json \
  | jq -e '.slideshow.title != null'
Enter fullscreen mode Exit fullscreen mode

HTTPie : curl avec une syntaxe plus lisible

HTTPie propose une syntaxe pensée pour l’exploration manuelle : les en-têtes et champs JSON s’écrivent sous forme de paires simples, et la sortie est formatée par défaut.

python -m pip install httpie
# ou
brew install httpie

# age:=24 est envoyé comme nombre ; name=acme comme chaîne
http POST httpbin.org/post name=acme age:=24 plan=pro
Enter fullscreen mode Exit fullscreen mode

Idéal pour : explorer une API depuis le terminal avec une sortie lisible.

Limite : HTTPie dépend de Python. Son démarrage est donc plus lent qu’un binaire compilé, et il reste avant tout un client HTTP, pas un moteur d’assertions.

xh : l’ergonomie de HTTPie dans un binaire Rust

xh reprend la syntaxe de HTTPie dans un binaire Rust. Vous gardez les paires clé=valeur, mais avec un démarrage rapide et sans runtime Python.

brew install xh
# ou
cargo install xh --locked

# Syntaxe compatible avec l'approche HTTPie
xh POST httpbin.org/post name=acme age:=24 plan=pro
Enter fullscreen mode Exit fullscreen mode

Pour obtenir la commande curl équivalente :

xh --curl GET https://httpbin.org/get
Enter fullscreen mode Exit fullscreen mode

Idéal pour : les développeurs qui apprécient HTTPie mais préfèrent un binaire unique et rapide.

Limite : son écosystème est plus petit que celui de HTTPie et il ne remplace pas un outil de tests avec assertions.

Hurl : des tests HTTP en texte brut pour la CI

Hurl transforme des requêtes HTTP en fichiers .hurl versionnables. Chaque fichier contient la requête, la réponse attendue et les assertions à vérifier.

brew install hurl
# ou
cargo install --locked hurl

cat > login.hurl <<'EOF'
POST https://httpbin.org/post
{ "user": "acme", "plan": "pro" }

HTTP 200
[Asserts]
jsonpath "$.json.user" == "acme"
EOF

# Retourne un code non nul si une assertion échoue
hurl --test login.hurl
Enter fullscreen mode Exit fullscreen mode

Vous pouvez l’intégrer directement dans une étape CI :

hurl --test tests/*.hurl
Enter fullscreen mode Exit fullscreen mode

Idéal pour : les tests de fumée et les vérifications de contrat HTTP conservés sous forme de fichiers texte relisibles en pull request.

Limite : Hurl est focalisé sur HTTP. Il ne remplace pas un outil de charge ni un client gRPC complet.

Step CI : un workflow YAML en plusieurs étapes

Step CI décrit un flux API dans un fichier YAML. Il couvre REST, GraphQL, gRPC, tRPC et SOAP, et peut valider des interactions contre un schéma OpenAPI.

npm install -g stepci

# workflow.yml contient les étapes, captures et assertions
stepci run workflow.yml
Enter fullscreen mode Exit fullscreen mode

Un flux typique peut inclure :

  1. Connexion utilisateur.
  2. Extraction d’un jeton depuis la réponse.
  3. Réutilisation du jeton dans une requête suivante.
  4. Vérification du statut, du corps et des en-têtes.

Idéal pour : les workflows déclaratifs multi-étapes exécutés de la même façon en local et dans la CI.

Limite : Step CI nécessite Node.js et est donc plus lourd qu’un binaire Rust ou Go. Vérifiez également l’activité récente du dépôt avant de l’adopter pour un pipeline critique.

Pour structurer ces scénarios dans une stratégie plus large, consultez les stratégies de test d’API.

k6 : tester la charge depuis le terminal

k6 répond à une autre question : non pas « la réponse est-elle correcte ? », mais « l’API tient-elle sous charge ? ».

Il est distribué comme un binaire Go et utilise JavaScript pour définir les scénarios. Les seuils permettent de faire échouer automatiquement une exécution lorsque les performances se dégradent.

brew install k6
# ou
docker run grafana/k6

cat > load.js <<'EOF'
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  vus: 10,
  duration: '30s',
  thresholds: {
    http_req_duration: ['p(95)<500'],
  },
};

export default function () {
  const res = http.get('https://httpbin.org/get');

  check(res, {
    'status is 200': (r) => r.status === 200,
  });
}
EOF

k6 run load.js
Enter fullscreen mode Exit fullscreen mode

Si un seuil est dépassé, k6 quitte avec le code 99, ce qui permet à la CI d’échouer correctement.

Idéal pour : les tests de performance et de charge scriptables sans devoir déployer un cluster.

Limite : k6 n’est pas conçu pour inspecter manuellement une seule réponse ou pour remplacer un client HTTP interactif.

Newman : exécuter des collections Postman sans interface graphique

Newman est l’exécuteur CLI des collections Postman. Si vos requêtes et assertions existent déjà dans Postman, vous pouvez les exporter en JSON et les lancer dans un pipeline.

npm install -g newman

# collection.json est exporté depuis Postman
# staging.json contient éventuellement les variables d'environnement
newman run collection.json -e staging.json
Enter fullscreen mode Exit fullscreen mode

Exemple d’utilisation en CI :

newman run collection.json \
  -e staging.json \
  --reporters cli,junit \
  --reporter-junit-export reports/newman.xml
Enter fullscreen mode Exit fullscreen mode

Idéal pour : les équipes déjà investies dans Postman et qui veulent exécuter leurs collections sans interface graphique.

Limite : Newman dépend de Node.js et du format de collection Postman. La création des scénarios reste généralement réalisée dans Postman.

Apidog CLI : exécuter des scénarios visuels dans la CI

Apidog CLI est le package npm apidog-cli. Il exécute depuis le terminal les scénarios de test construits dans Apidog : enchaînements de requêtes, variables extraites et assertions.

npm install -g apidog-cli

apidog login --with-token <YOUR_TOKEN>

# Copiez cette commande depuis l'onglet CI/CD du scénario Apidog
apidog run -t <scenario_id> -e <env_id> -r cli
Enter fullscreen mode Exit fullscreen mode

Pour l’intégrer à une CI :

apidog run -t <scenario_id> -e <env_id> -r cli,junit
Enter fullscreen mode Exit fullscreen mode

Ne renseignez pas les identifiants à la main : ouvrez le scénario dans Apidog, allez dans l’onglet CI/CD, puis copiez la commande apidog run générée.

Le rapporteur -r cli affiche les résultats étape par étape dans le terminal. La commande retourne 0 lorsque toutes les assertions réussissent, et un code non nul en cas d’échec. Un pipeline peut donc l’utiliser directement comme porte de validation.

Idéal pour : les équipes qui créent des scénarios complexes dans un éditeur visuel, puis les exécutent sans interface graphique depuis une CI ou un agent.

Limite : contrairement à curl ou xh, cet outil est lié aux scénarios stockés dans un projet Apidog. Ce n’est pas un client HTTP autonome.

Pour aller plus loin, consultez le guide complet d’Apidog CLI, la référence de la commande apidog run et le guide pour tester une API REST depuis la ligne de commande avec Apidog CLI.

Comment choisir

Outil Idéal pour Installation Open source ? Notes
curl Requêtes ponctuelles, scripts Préinstallé Oui (MIT/curl) Universel ; assertions manuelles
HTTPie Requêtes manuelles lisibles pip install httpie Oui (BSD-3) Syntaxe conviviale ; runtime Python
xh Ergonomie HTTPie, démarrage rapide brew install xh Oui (MIT) Binaire Rust unique
Hurl Tests HTTP en texte brut brew install hurl Oui (Apache-2.0) --test exploitable en CI
Step CI Flux YAML multi-étapes npm i -g stepci Oui (MPL-2.0) REST, GraphQL, gRPC ; runtime Node
k6 Charge et performance brew install k6 Oui (AGPL-3.0) Scripts JavaScript ; seuils bloquants
Newman Collections Postman en CI npm i -g newman Oui (Apache-2.0) Exécute les exports Postman JSON
Apidog CLI Scénarios visuels exécutés sans GUI npm i -g apidog-cli Non (niveau gratuit) Code de sortie et sortie JSON structurée

Commencez avec curl ou xh pour sonder rapidement un endpoint. Passez à Hurl quand ces vérifications doivent être versionnées et exécutées automatiquement. Ajoutez k6 lorsque la performance devient un critère, et Newman lorsque vos tests sont déjà dans Postman.

Choisissez Apidog CLI si vous préférez construire visuellement un scénario multi-étapes, puis l’exécuter dans un terminal, un pipeline ou un agent. Pour comparer cette approche avec d’autres solutions, consultez les outils de test d’API sans interface graphique.

Où les outils légers sont rentables

Les outils CLI légers sont particulièrement utiles lorsque l’interface graphique devient une friction :

  • vous êtes déjà dans un terminal ;
  • vous devez valider une API dans une CI ;
  • vous voulez versionner des tests lisibles ;
  • un agent ou un script doit interpréter un code de sortie.

curl et xh accélèrent les vérifications manuelles. Hurl et Step CI rendent les requêtes reproductibles. k6 traite la charge. Newman exécute vos collections Postman existantes.

Avec Apidog, vous pouvez concevoir un scénario une fois, puis lancer apidog run depuis un terminal ou un pipeline. Téléchargez Apidog, créez un scénario et ajoutez la commande générée à votre configuration CI.

Top comments (0)