Générateur de commandes cURL — Une requête HTTP sans tâtonner
Générateur de commandes curl
Authentification
En-têtes
Corps de la requête
curl \ -H 'Accept: application/json' \ 'https://api.example.com/v1/items?page=2'
La commande est assemblée dans votre navigateur et n’est envoyée nulle part. Les valeurs contenant des espaces ou des métacaractères du shell sont entourées d’apostrophes simples afin que la commande s’exécute telle quelle en toute sécurité ; un guillemet littéral contenu dans une valeur est échappé à la manière POSIX.
Ce Qui Est
curl — client URL — est le programme en ligne de commande qui transfère des données vers et depuis un serveur en utilisant une syntaxe d'URL. Il est livré avec macOS, il fait partie de l'installation de base de Git pour Windows, et il est présent dans pratiquement tous les runners d'intégration continue, toutes les images de conteneurs et tous les shells distants que tu ouvriras. Né en 1998 pour récupérer des pages web depuis un terminal, il est devenu le client HTTP universel : HTTP/1.1 et HTTP/2, HTTPS, proxys, cookies, redirections, ainsi que FTP et SFTP. Toute commande cURL se lit de la même façon, parce que chaque option correspond à une partie de la requête : - L'option de méthode. -X suivi d'un verbe fixe la méthode HTTP. Pour GET, la valeur par défaut de curl, l'option peut être omise : un curl suivi d'une URL fait déjà un GET, et il en va de même pour HEAD. Pour POST, PUT, PATCH, DELETE et OPTIONS, c'est cette option qui indique au serveur ce que tu fais. - Les options d'en-tête. Chaque -H 'Nom : valeur' ajoute un en-tête HTTP. Accept indique le format de réponse souhaité, Content-Type décrit le corps envoyé, et tout autre nom passe tel quel. Les noms d'en-têtes ne sont pas sensibles à la casse sur le réseau. - Les options d'authentification. -u 'utilisateur:motdepasse' réalise l'authentification Basic : curl encode la paire en base64 et la place dans un en-tête Authorization.
Il n'existe pas d'option dédiée au Bearer ; le jeton s'envoie avec -H 'Authorization: Bearer ...'. La distinction vaut la peine d'être comprise, car -u n'est qu'un raccourci vers un en-tête précis et non un second système d'identifiants : écrire à la main ce même en-tête Authorization produit une requête identique octet pour octet. - Les options de données. -d, --data et --data-raw ajoutent tous un corps de requête, et --data-urlencode encode en pourcentage une seule paire nom=valeur. Un comportement surprend : dès que tu ajoutes une option de données, curl bascule la méthode sur POST sauf si tu écris -X toi-même, si bien qu'un PUT accompagné d'un corps peut discrètement créer une ressource au lieu de la modifier. Ce générateur rend cette règle visible : si tu choisis un corps alors que la méthode est encore GET, un -X POST apparaît tout seul. - L'URL. Elle vient en dernier, sans guillemets si elle est simple, avec guillemets si elle porte une chaîne de requête. Les guillemets sont le lieu où meurent la plupart des commandes écrites à la main. Le shell interprète l'espace, &, |, ;, $, >, *, ?, les parenthèses, l'apostrophe et le guillemet double comme de la syntaxe et non comme des données. Une URL collée sous la forme https://api.example.com/recherche?q=a&b=2 est coupée au & : curl demande /recherche?q=a et le shell essaie ensuite d'exécuter le reste, b=2, ce qui produit une erreur de commande introuvable sans rapport avec le service. Le même sort attend tout corps JSON, car les espaces à l'intérieur des accolades le découpent en plusieurs arguments. Entourer la valeur de guillemets simples dit au shell de tout transmettre littéralement.
Les guillemets simples sont l'enveloppe la plus sûre car rien à l'intérieur n'est interprété : ni le signe dollar, ni un accent grave, ni un second guillemet. Le seul problème, c'est une valeur qui contient elle-même un guillemet simple, impossible à échapper entre guillemets simples. POSIX résout cela en fermant le guillemet, en insérant un guillemet échappé par une barre oblique inverse, puis en rouvrant le guillemet — exactement la forme que cet outil produit dès qu'il rencontre une apostrophe dans une valeur d'en-tête ou dans un mot de passe. Un autre concept compte quand la commande tourne sans surveillance : l'idempotence. GET, HEAD, PUT et DELETE sont idempotents par définition,autrement dit, répéter la requête laisse le serveur dans le même état que de l'envoyer une fois, si bien qu'une reprise sur erreur réseau est sans conséquence. POST ne l'est pas : une requête POST rejouée peut créer deux enregistrements ou débiter deux fois une carte. C'est pourquoi curl ne retente par défaut que les méthodes idempotentes, et pourquoi --retry reste sûr dans un script qui mélange plusieurs verbes. Enfin, comment lire la sortie. Par défaut curl dessine une barre de progression sur la sortie d'erreur : pourcentage, octets téléchargés et total, vitesse actuelle et temps restant estimé. Elle disparaît dès que tu rediriges la sortie dans un fichier ou un tube, et --silent la supprime complètement. -v affiche la conversation entière, avec < pour ce que curl envoie et > pour ce qu'il reçoit : la ligne de requête, chaque en-tête envoyé, la ligne de statut de la réponse et chaque en-tête reçu. -i conserve les en-têtes de réponse dans le corps au lieu de les jeter, et --fail fait sortir curl avec un code non nul sur une réponse 4xx ou 5xx, ce qu'on veut précisément dans un script.
Comment utiliser
- Choisis le verbe attendu par ton endpoint dans la liste Method : GET, POST, PUT, PATCH, DELETE, HEAD ou OPTIONS. La commande du bas se met à jour aussitôt et n'ajoute pas -X pour GET et HEAD.
- Colle l'URL complète dans le champ URL, schéma et chaîne de requête compris, par exemple https://api.example.com/v1/items?page=2.
- Dans Authentication, clique sur None, Basic ou Bearer. Basic fait apparaître les champs Username et Password et produit -u ; Bearer affiche un unique champ de jeton et construit l'en-tête Authorization à ta place.
- Travaille dans la section Headers : coche la case de chaque ligne pour l'inclure ou l'exclure, remplis les champs Header name et Header value, clique sur × pour supprimer une ligne inutile ou sur + Add header pour en créer une autre.
- Choisis le type de corps dans Request body : No body, JSON, Form fields ou Raw text. JSON et Form fields ajoutent le Content-Type correspondant, sauf si tu as déjà saisi toi-même un en-tête Content-Type.
- En mode JSON, coche Pretty-print pour que le corps soit ressérialisé avec une indentation, ou laisse la case vide pour conserver exactement ce que tu as tapé. Form fields transforme chaque ligne nom=valeur en un flag --data-urlencode distinct.
- Lis la commande assemblée dans le bloc Command et appuie sur Copy pour mettre la version sur une seule ligne dans le presse-papiers. L'assemblage a lieu dans ton navigateur, donc les identifiants présents dans la commande ne sont transmis nulle part.
Exemples
Entrée: GET https://api.example.com/v1/items?page=2 avec l'en-tête Accept: application/json
Processus:
GET étant la méthode par défaut de curl, -X est omis, l'en-tête est émis avec -H et l'URL conserve sa chaîne de requêteRésultat: curl \
-H 'Accept: application/json' \
https://api.example.com/v1/items?page=2
Entrée: POST https://api.example.com/v1/items avec un corps JSON {"name":"example","active":true} et un jeton Bearer
Processus:
Le corps JSON produit -X POST et le Content-Type, le jeton devient un en-tête Authorization et la charge utile est entre guillemets simplesRésultat: curl \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer eyJhbGciOi...' \
--data-raw '{
"name": "example",
"active": true
}' \
https://api.example.com/v1/items
Entrée: POST https://api.example.com/login avec Form fields name=ada&password=secret et auth Basic ada:hunter2
Processus:
L'auth Basic devient -u, chaque champ du formulaire son propre flag --data-urlencode, et le Content-Type urlencoded est ajoutéRésultat: curl \
-H 'Content-Type: application/x-www-form-urlencoded' \
-u 'ada:hunter2' \
--data-urlencode 'name=ada' \
--data-urlencode 'password=secret' \
https://api.example.com/login
Entrée: DELETE https://api.example.com/v1/items/42 avec l'en-tête personnalisé X-Request-Id: 8f14e45f
Processus:
DELETE n'a pas de corps donc -X DELETE est explicite, l'en-tête personnalisé est cité, et rien n'est ajouté que tu n'aies demandéRésultat: curl \
-X DELETE \
-H 'X-Request-Id: 8f14e45f' \
https://api.example.com/v1/items/42
Recherches Connexes
Les gens recherchent aussi : générateur de commande curl, créer une commande curl, commande curl en ligne, curl avec en-têtes, curl authentification basique, curl jeton bearer.
générateur de commande curlcréer une commande curlcommande curl en lignecurl avec en-têtescurl authentification basiquecurl jeton bearercurl envoyer du jsoncurl données de formulairesyntaxe curltester une api avec curlclient http ligne de commandeguillemets shelloutil développeurgénérateur de requête httpcurl et authentificationdéboguer une api restexemple de commande curloutil en ligne gratuit
Questions Fréquemment Posées
Pourquoi le générateur n'ajoute-t-il pas -X aux requêtes GET ?
Parce qu'un curl sans option suivi d'une URL effectue déjà un GET : l'option serait purement décorative. Le même raisonnement vaut pour HEAD, qui ne demande que les en-têtes. Pour POST, PUT, PATCH, DELETE et OPTIONS la méthode doit être déclarée, donc l'option est émise. Si tu dois un jour parler à un endpoint Qui réclame un verbe inhabituel, ajoute toi-même une ligne d'en-tête personnalisée et elle apparaîtra dans la commande.
Faut-il utiliser -u ou écrire soi-même l'en-tête Authorization ?
Les deux produisent exactement la même requête. -u 'utilisateur:motdepasse' est un raccourci qui encode la paire en base64 et envoie un en-tête Authorization: Basic, t'épargnant ce travail. Écrire l'en-tête à la main n'a d'intérêt que si le schéma d'authentification est propriétaire, si le jeton contient des caractères que tu préfères lire depuis un fichier plutôt que taper sur la ligne de commande, ou si le mot de passe contient lui-même deux-points, puisque tout ce qui suit le premier est pris pour le mot de passe.
Pourquoi mon corps JSON doit-il être entouré de guillemets simples ?
Parce que le shell analyse la ligne de commande avant que curl ne reçoive ses arguments, et qu'un corps JSON sans guillemets est rempli d'espaces, d'accolades, de guillemets et de deux-points que le shell prend pour de la syntaxe. Sans guillemets, la charge utile se découpe en plusieurs arguments et curl affiche un message de données manquantes d’autant plus déroutant. Entre guillemets simples, chaque caractère passe littéralement, y compris les guillemets doubles dont JSON a besoin. Ce générateur cite toute valeur qui n'est pas purement alphanumérique sûre, la commande est donc exécutable telle quelle.
Le générateur ajoute-t-il le Content-Type à ma place ?
Oui, mais seulement si tu n'en as pas fourni toi-même. Choisir le corps JSON ajoute Content-Type: application/json et choisir Form fields ajoute Content-Type: application/x-www-form-urlencoded. Si une ligne Content-Type existe déjà dans la liste, il saute la sienne pour éviter d'envoyer deux fois le même en-tête avec des valeurs contradictoires. Envoyer du JSON sans Content-Type est une cause fréquente d'erreur 400 : le serveur suppose un encodage de formulaire et échoue à lire ta charge utile.
Est-il prudent de coller ici un vrai jeton Bearer ou un vrai mot de passe ?
Oui en ce qui concerne l'envoi de données. La commande est produite par du JavaScript qui s'exécute dans l'onglet de ton navigateur : l'URL, les identifiants et les en-têtes ne quittent jamais ta machine et n'atteignent pas nos serveurs. Rien n'est stocké, rien n'est journalisé, et fermer l'onglet fait disparaître les valeurs. Reste néanmoins prudent comme d'habitude : un jeton saisi dans une page peut être exposé par une extension, et une commande collée dans un terminal finit dans ton historique, donc utilise des valeurs de remplacement dans toute documentation partagée.
Comment envoyer des données de formulaire au lieu de JSON ?
Sélectionne Form fields dans la section Request body et écris une paire nom=valeur par ligne ; tout sur une seule ligne séparé par des esperluettes fonctionne aussi, l'outil le découpe. Chaque paire devient son propre flag --data-urlencode 'nom=valeur' et le Content-Type passe automatiquement à application/x-www-form-urlencoded. Utilise l'encodage en pourcentage plutôt qu'une esperluette brute dans les valeurs qui contiennent des caractères réservés, sinon le serveur recevra un champ tronqué.
Pourquoi l'ajout d'un corps change-t-il ma méthode en POST ?
C'est le comportement de curl lui-même : quand tu attaches des données avec -d ou --data-raw sans indiquer de méthode, curl suppose POST. Le générateur le reproduit honnêtement au lieu de le cacher, donc si la liste affiche encore GET et que tu ajoutes un corps, tu verras apparaître -X POST. Choisis d'abord la vraie méthode dans la liste, ou corrige après coup, pour qu'une mise à jour ne se transforme pas silencieusement en création.