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

La plupart des outils de test d'API vous demandent d'ouvrir une fenêtre, de vous connecter et de naviguer dans un espace de travail avant de pouvoir envoyer une seule requête. C'est bien pour un premier aperçu. Mais ce n'est pas adapté au terminal, où vous voulez taper une ligne, lire la réponse et passer à autre chose. Les outils légers en ligne de commande inversent cet ordre : l'outil s'efface, et la requête est toute l'interaction.

Léger signifie ici quelque chose de spécifique. Une petite installation, souvent un seul binaire ou un npx rapide. Un démarrage rapide, de sorte que l'atteinte d'un point de terminaison semble instantanée. Peu ou pas de configuration pour exécuter la première requête. Une sortie adaptée au terminal que vous pouvez rediriger vers jq ou grep. C'est une question différente de "quel outil est open source" ou "lequel a le plus de fonctionnalités". Il s'agit d'encombrement et de friction. Pour un aperçu plus large couvrant également les interfaces graphiques hébergées, consultez le tour d'horizon des meilleurs outils de test d'API gratuits.

Vous trouverez ci-dessous huit outils CLI légers pour tester les API REST et HTTP, classés approximativement du plus petit et manuel aux plus complets pour les suites de tests en CI. Chaque entrée contient une commande d'installation réelle, une commande qui montre son fonctionnement, ce pour quoi elle est la meilleure, et une limite honnête. Le dernier, l'Apidog CLI, est le binaire léger qui exécute les scénarios que vous construisez visuellement et conditionne un pipeline à son code de sortie.

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

De nombreux outils s'exécutent dans un terminal. Tous ne sont pas légers. Pour cette liste, un outil est qualifié sur quatre points :

• Encombrement réduit. Un seul binaire, une installation pip/npm, ou une seule ligne npx. Pas de runtime à configurer au préalable, idéalement pas de démon.
• Démarrage rapide. L'outil se lance et envoie la requête sans préchauffage. Les binaires Rust et Go l'emportent ici ; tout ce qui démarre un runtime lourd perd.
• Configuration faible ou nulle. Vous pouvez envoyer la première requête sans fichier de projet, sans compte, sans connexion. La configuration est optionnelle, pour quand vous voulez sauvegarder et répéter.
• Sortie native au terminal. Les résultats s'affichent sous une forme que vous pouvez lire d'un coup d'œil et rediriger vers une autre commande. Les codes de sortie ont un sens, de sorte que la CI peut s'y baser.

Les outils se concentrent sur les trois premiers points ; les deux derniers s'appuient sur le quatrième, car c'est là qu'un binaire léger gagne sa place dans un pipeline. Si vous souhaitez approfondir le côté interactif, "atteindre un point de terminaison à la main", le guide sur les alternatives à curl pour les tests d'API REST explore davantage les clients manuels.

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

curl est l'outil que vous avez très probablement déjà. Il est livré sur macOS, la plupart des distributions Linux et Windows modernes, donc l'installation la plus légère est aucune installation. Il prend en charge HTTP, HTTPS et une longue liste d'autres protocoles, et c'est la référence à laquelle tous les autres clients se mesurent.

# Déjà sur votre machine ; vérifiez la version
curl --version

# POST JSON et n'affiche 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"}'

Idéal pour : les requêtes ponctuelles rapides, les scripts et tout environnement où vous ne pouvez pas installer de nouveau logiciel. Limite honnête : l'ergonomie est datée. Vous définissez les en-têtes à la main, le JSON n'est pas joliment formaté, et l'assertion sur une réponse signifie la rediriger vers jq et vérifier vous-même un code de sortie. Il envoie et affiche ; il ne teste pas.

HTTPie : curl pour les humains

HTTPie fait les mêmes requêtes que curl, avec une syntaxe conçue pour les personnes. La commande est http, les en-têtes et les champs JSON sont de simples paires clé=valeur, et la sortie est colorée et formatée par défaut. Il est écrit en Python, il a donc besoin d'un runtime Python, ce qui le rend plus lourd qu'un seul binaire mais reste une installation en une ligne.

python -m pip install httpie   # ou : brew install httpie

# POST JSON : age:=24 envoie un nombre, name= envoie une chaîne de caractères
http POST httpbin.org/post name=acme age:=24 plan=pro

Idéal pour : explorer une API à la main lorsque vous voulez une sortie lisible sans drapeaux. Limite honnête : le démarrage de Python est sensiblement plus lent qu'un binaire compilé, et l'installation sur un système vierge signifie l'ajout de Python s'il n'est pas déjà présent. Comme curl, c'est un client, pas un exécuteur de tests ; vous lisez la réponse, vous ne l'affirmez pas.

xh : la vitesse de HTTPie dans un seul binaire

xh réimplémente la syntaxe conviviale de HTTPie en Rust et est livré sous la forme d'un seul binaire lié statiquement. Vous obtenez la même ergonomie clé=valeur et une sortie colorée, avec un démarrage plus rapide et rien à installer au-delà du binaire lui-même. Il prend en charge HTTP/2 et peut même afficher la commande curl équivalente avec --curl.

brew install xh   # ou : cargo install xh --locked

# Même syntaxe que HTTPie, démarrage plus rapide
xh POST httpbin.org/post name=acme age:=24 plan=pro

Idéal pour : les développeurs qui apprécient la sensation HTTPie mais souhaitent un binaire unique et rapide sans runtime. Limite honnête : il n'implémente pas toutes les fonctionnalités d'HTTPie et il n'y a pas de système de plugins. Il est plus jeune qu'HTTPie, donc son écosystème est plus petit. Toujours un client, pas un moteur d'assertion.

Hurl : des tests en texte brut qui s'exécutent en CI

Hurl est le point où cette liste passe de "envoyer une requête" à "tester une réponse". Il exécute des requêtes HTTP écrites dans un fichier .hurl en texte brut et effectue des assertions sur les résultats. Il est écrit en Rust, alimenté par libcurl en coulisses, et est livré sous forme de binaire unique sans runtime. Les tests se lisent presque comme les requêtes elles-mêmes, ce qui les rend faciles à revoir dans une pull request.

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

hurl --test login.hurl   # code de sortie non nul si une assertion échoue

Idéal pour : les vérifications de type contrat et les tests de fumée que vous conservez sous contrôle de version sous forme de texte lisible. L'indicateur --test en fait une passerelle CI propre ; une assertion échouée renvoie un code de sortie non nul. Limite honnête : il est axé sur HTTP, il ne pilotera donc pas gRPC et ne générera pas de charge réelle. Les flux complexes impliquent plus de fichiers .hurl plutôt qu'un langage de script.

Step CI : un seul fichier YAML pour un flux en plusieurs étapes

Step CI exécute des workflows d'API décrits dans un seul fichier YAML. Il couvre REST, GraphQL, gRPC, tRPC et SOAP dans un même workflow, et peut valider par rapport à un schéma OpenAPI. Vous l'installez via npm et exécutez le même fichier localement et en CI. Il se lit bien lorsqu'un test est réellement une séquence : se connecter, capturer un jeton, l'utiliser lors de l'appel suivant, vérifier le résultat.

npm install -g stepci

# workflow.yml décrit les étapes, les captures et les vérifications
stepci run workflow.yml

Idéal pour : les équipes qui souhaitent un fichier déclaratif unique décrivant un flux d'API multi-étapes, exécuté de manière identique sur un ordinateur portable et dans un pipeline. Limite honnête : c'est un package Node, donc il est plus lourd qu'un binaire Rust ou Go, et il nécessite un runtime. La cadence de publication a ralenti, alors vérifiez l'activité récente du dépôt avant de construire un pipeline dessus. Pour savoir comment ces éléments s'intègrent dans un plan de test plus complet, consultez les stratégies de test d'API.

k6 : tests de charge légers depuis le terminal

k6 répond à une question différente : non pas "cette réponse est-elle correcte", mais "tient-elle sous la charge". Il est écrit en Go, est livré sous forme de binaire statique unique, et les scripts sont du JavaScript pur. Il est conçu pour une utilisation minimale des ressources, afin que vous puissiez générer un trafic réel depuis un ordinateur portable. Les seuils transforment un test de charge en une validation "réussite/échec" ; si un seuil est dépassé, k6 quitte avec le code 99, ce qu'un pipeline interprète comme un échec.

brew install k6   # ou exécutez via Docker : 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

Idéal pour : les vérifications de performance et de charge que vous souhaitez scripter et exécuter en CI sans avoir à mettre en place un cluster. Limite honnête : c'est un outil de charge, pas un client de test fonctionnel ; vous ne l'utiliseriez pas pour examiner une seule réponse. Écrire des scénarios significatifs implique d'apprendre son API JavaScript.

Newman : exécutez une collection Postman sans interface graphique

Newman est l'exécuteur en ligne de commande pour les collections Postman. Si votre équipe construit déjà des requêtes et des tests dans Postman, Newman exécute cette collection exacte depuis un terminal sans interface graphique, ce dont vous avez besoin en CI. Vous exportez la collection (et éventuellement un environnement) au format JSON et la pointez vers Newman.

npm install -g newman

# collection.json exportée de Postman ; -e passe un environnement
newman run collection.json -e staging.json

Idéal pour : les équipes investies dans Postman qui souhaitent que leurs collections existantes s'exécutent sans interface graphique dans un pipeline. Newman renvoie un code de sortie non nul en cas d'échec de test, ce qui permet de gérer proprement la CI. Limite honnête : c'est un package Node, donc il est plus lourd et ne fonctionne qu'avec les collections au format Postman, il est donc surtout utile si vous êtes déjà dans cet écosystème. Il exécute des tests que quelqu'un a construits dans une interface graphique ; la création se fait toujours là.

Apidog CLI : exécutez les scénarios que vous avez construits, conditionnez la CI au code de sortie

L'Apidog CLI est l'extrémité légère d'Apidog. C'est un package npm, apidog-cli, qui exécute les scénarios de test que vous avez conçus visuellement dans Apidog directement depuis un terminal. La partie création du test reste dans l'interface graphique, où l'enchaînement des requêtes, l'extraction de variables et l'écriture d'assertions sont rapides ; l'interface CLI est le petit morceau qui exécute l'un de ces scénarios sans interface graphique et vous donne un code de sortie. Apidog n'est pas open source, mais son niveau gratuit plus cette interface CLI vous offre une alternative intégrée pour assembler un client, un exécuteur et un outil de charge séparés.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>

# Copiez la commande exacte depuis l'onglet CI/CD de votre scénario
apidog run -t <scenario_id> -e <env_id> -r cli

Vous ne devinez pas les identifiants de scénario et d'environnement. Ouvrez votre scénario de test dans Apidog, accédez à l'onglet CI/CD, et copiez la commande apidog run générée avec les identifiants déjà renseignés. Le rapporteur -r cli affiche un résultat étape par étape et un résumé dans le terminal ; ajoutez -r cli,junit lorsqu'un tableau de bord CI doit analyser les résultats. Comme les outils ci-dessus, apidog run quitte avec 0 lorsque toutes les assertions réussissent et avec un code non nul lorsque quelque chose échoue, de sorte qu'un pipeline le traite comme une porte propre. Sa sortie est un JSON structuré avec agentHints.nextSteps, ce qui facilite également son exécution et sa lecture par un agent de codage IA.

Idéal pour : les équipes qui veulent créer des scénarios complexes en plusieurs étapes dans un éditeur visuel mais les exécuter sans interface graphique en CI ou à partir d'un agent. Limite honnête : contrairement à curl ou xh, il est lié aux scénarios que vous conservez dans un projet Apidog, c'est donc l'option de plateforme intégrée, pas un simple client HTTP. Pour l'ensemble complet des commandes, consultez le guide complet d'Apidog CLI, la référence de la commande apidog run, et la procédure pas à pas sur la façon de tester une API REST depuis la ligne de commande avec Apidog CLI.

Comment choisir

Le bon outil dépend de la distance que vous devez parcourir au-delà de "envoyer une seule requête".

Commencez par le haut pour les tâches manuelles. Utilisez curl ou xh pour sonder un point d'accès. Passez à Hurl lorsque vous souhaitez que ces vérifications s'exécutent en contrôle de version. Intégrez k6 lorsque la question porte sur la charge, et Newman si vos tests sont déjà dans Postman. Choisissez l'Apidog CLI lorsque vous préférez créer un scénario complexe dans un éditeur et l'exécuter sans interface graphique partout ailleurs. Si vous pesez ces options par rapport à un workflow GUI complet sans interface, le guide des outils de test d'API sans interface graphique couvre l'exécution de tests sans aucune interface.

Où les outils légers sont rentables

Les outils CLI légers l'emportent les jours où une interface graphique vous ralentit : lorsque vous êtes plongé dans un terminal, lorsqu'un test doit s'exécuter en CI sans intervention humaine, et de plus en plus, lorsqu'un agent IA effectue la vérification pour vous. curl et xh maintiennent la boucle manuelle serrée. Hurl et Step CI transforment les requêtes ad hoc en tests reproductibles. k6 répond à la question de la charge. Newman exécute ce que vous avez déjà construit dans Postman.

L'Apidog CLI réduit l'écart entre la création d'un test et son exécution n'importe où. Vous concevez le scénario une fois dans Apidog, puis apidog run le lance depuis un terminal, un pipeline ou un agent, et le code de sortie décide si la compilation reste au vert. Téléchargez Apidog, construisez un scénario et insérez sa commande apidog run dans votre configuration CI pour voir la boucle se refermer.