Gratuit · Sans inscription · 6 régions AWS

curl en ligne gratuit : envoyez toute requête HTTP depuis votre navigateur

Un testeur d'API en ligne qui fonctionne comme curl. Choisissez la méthode, ajoutez des en-têtes et un corps, et lisez le code de statut, le corps de la réponse et la répartition du temps, depuis six régions AWS à la fois.

En-têtes de la requête
Toute méthode · En-têtes personnalisés · Corps de la réponse · Six régions pour GET

curl, sans le terminal

C'est la commande curl que vous auriez tapée, sous forme de formulaire. Choisissez GET, POST, PUT, PATCH, DELETE, HEAD ou OPTIONS, ajoutez les en-têtes attendus par l'API, collez un corps JSON ou brut pour les méthodes qui en acceptent un, et envoyez. LoadFocus effectue la requête depuis ses propres serveurs et vous montre exactement ce qui est revenu : le code de statut, chaque en-tête de réponse, le corps, le certificat SSL et une répartition du temps passé. Rien à installer, aucune inscription.

Un testeur d'API qui répond aux questions que curl ignore

Un terminal affiche un résultat depuis un seul endroit. Ici, une requête GET, HEAD ou OPTIONS part de six régions AWS en même temps, ce qui permet de voir si l'API répond différemment à Tokyo et en Virginie, car c'est ce que vivent réellement vos utilisateurs à Tokyo. Les requêtes qui modifient des données, c'est-à-dire POST, PUT, PATCH et DELETE, sont envoyées exactement une fois, depuis une seule région, parce qu'une requête qui crée ou supprime quelque chose ne doit pas être répétée six fois en votre nom.

De vraies requêtes, envoyées avec précaution

La requête part vers l'adresse que vous saisissez, avec la méthode et les en-têtes que vous définissez, et le point de terminaison la traite comme réelle. C'est l'intérêt de l'outil et aussi la raison de sa prudence : une requête qui modifie des données n'est jamais relancée, et si elle expire, le résultat indique une issue inconnue plutôt que de prétendre qu'elle a échoué, car le serveur peut très bien l'avoir traitée. Les redirections sont signalées, pas suivies. Les noms d'en-tête sont validés, les en-têtes hop-by-hop sont écartés, et votre en-tête Authorization est envoyé à l'API que vous avez nommée et n'est jamais écrit dans un journal.

D'une requête à savoir quand ça casse

Une requête envoyée à la main vous dit que l'API fonctionne maintenant. La même requête, envoyée chaque minute depuis plus de 25 régions avec des vérifications du code de statut et du corps, vous prévient à l'instant où elle cesse de fonctionner, avant qu'un client ne le fasse. C'est le moniteur d'API de LoadFocus, et son offre gratuite commence exactement par la requête que vous venez d'envoyer.

Sur le même sujet : API Monitoring · API Status Checker · curl to k6 · curl to JMeter · Free API load test

Ce que montre le résultat, et comment le lire

Une requête renvoie plus qu'un code de statut. Voici les valeurs qui méritent d'être lues :

Code de statut HTTP

Comment le serveur a répondu. 2xx correspond à un succès, 3xx à une redirection (signalée, non suivie), 4xx signifie que la requête a été refusée, que la ressource est absente ou qu'une authentification est requise, 5xx que le serveur a échoué. Un 401 ou un 403 avec les bons en-têtes en place signifie généralement que la valeur de l'en-tête est fausse, pas l'outil.

Corps de la réponse

Ce que l'API a renvoyé, affiché en texte et mis en forme lorsqu'il s'agit de JSON. Les corps volumineux sont coupés à 64 Ko avec une note l'indiquant, et les réponses binaires comme les images sont signalées par leur taille plutôt qu'affichées. Le corps est montré uniquement en texte, jamais rendu, de sorte qu'une page qui renvoie du HTML ne peut rien exécuter ici.

En-têtes de réponse

Type de contenu, cache, CORS, compteurs de limitation et identification du serveur lui-même. Quand une API se comporte mal, la réponse se trouve souvent dans un en-tête : un Content-Type erroné, un Access-Control-Allow-Origin manquant ou un X-RateLimit-Remaining à zéro.

Temps jusqu'au premier octet (TTFB)

Le temps mis par le serveur pour commencer à répondre une fois la connexion prête. Sous 800 ms est correct pour une API. Un TTFB lent avec un DNS et un TLS rapides signifie que le travail est côté serveur : une requête lente, un cache froid ou un backend surchargé.

Temps DNS, connexion et TLS

Le coût pour atteindre le serveur avant même l'envoi de la requête. Un temps DNS élevé pointe vers le résolveur ou un serveur faisant autorité lent ; un temps TLS élevé vers la chaîne de certificats ou une négociation refaite à chaque appel au lieu d'être réutilisée.

Écart entre régions

Pour les méthodes sûres, la même requête est chronométrée depuis six régions. L'écart entre la plus rapide et la plus lente correspond à ce que voit réellement une audience mondiale, et un code de statut qui diffère selon la région signale généralement un déploiement ou un nœud CDN dont la propagation n'est pas terminée.

FAQ curl en ligne

Comment exécuter une commande curl en ligne ?

Saisissez l'URL, choisissez la méthode, ajoutez les en-têtes que vous auriez passés avec -H et, pour POST ou PUT, collez le corps que vous auriez passé avec -d. Cliquez sur Envoyer. La requête est effectuée depuis les serveurs de LoadFocus et le code de statut, les en-têtes et le corps reviennent sur cette page, avec la répartition du temps que curl vous montrerait avec --write-out.

Puis-je envoyer une requête POST avec un corps JSON ?

Oui. Choisissez POST, sélectionnez JSON comme type de corps et collez le contenu. L'en-tête Content-Type est défini sur application/json pour vous, sauf si vous ajoutez le vôtre. PUT, PATCH et DELETE acceptent un corps de la même façon. Les requêtes qui modifient des données sont envoyées une fois, depuis une seule région, et ne sont jamais relancées.

Est-ce aussi un testeur d'API en ligne ?

Oui. Tester une API consiste à envoyer une requête avec la bonne méthode, les bons en-têtes et le bon corps, puis à lire ce qui revient, et c'est exactement ce que fait cet outil. Ajoutez un en-tête Authorization pour les API qui en ont besoin ; il est envoyé à l'API que vous avez nommée et n'est ni journalisé ni conservé.

Pourquoi un GET part-il de six régions et un POST d'une seule ?

Une requête GET, HEAD ou OPTIONS peut être répétée sans risque, donc l'envoyer depuis six régions donne six mesures sans conséquence. Un POST, PUT, PATCH ou DELETE modifie quelque chose sur le serveur, et le répéter six fois créerait ou supprimerait six éléments. Ceux-là sont envoyés exactement une fois, et le résultat indique quelle région l'a envoyé.

Que se passe-t-il si ma requête expire ?

Pour une méthode sûre, la région est marquée comme expirée. Pour une requête qui modifie des données, le résultat est marqué comme inconnu, car le serveur peut l'avoir reçue et traitée même si la réponse n'est jamais arrivée. Elle n'est pas relancée automatiquement, et il vaut mieux vérifier avant de la renvoyer.

Les redirections sont-elles suivies ?

Non. Un code 3xx est signalé avec son en-tête Location afin que vous voyiez où l'API voulait vous envoyer, et vous pouvez ensuite envoyer vous-même une requête à cette adresse. Suivre les redirections automatiquement vous cacherait la redirection et pourrait aussi mener à un endroit que la vérification de l'URL d'origine n'a jamais examiné.

Puis-je exécuter cette requête selon un planning ?

Oui. Un moniteur d'API LoadFocus, c'est cette même requête, avec des vérifications du code de statut, du temps de réponse et du corps, exécutée chaque minute depuis plus de 25 régions avec des alertes par e-mail, Slack, Microsoft Teams, PagerDuty ou webhook. L'offre gratuite suffit pour surveiller le point de terminaison que vous venez de tester.
×