Testeur de requêtes API

Testeur de requêtes API - Vérifiez vos endpoints REST

Chaque intégration API commence de la même manière : lire la documentation, envoyer une requête de test faite à la main, inspecter la réponse, puis écrire le code de production uniquement après avoir confirmé le contrat. Pendant des décennies, ce flux de travail a signifié Postman, Insomnia, curl ou HTTPie — tous nécessitant d'installer un logiciel. Cet outil place le même flux dans un onglet de navigateur pour que vous puissiez taper un endpoint rapide sans quitter votre contexte de développement actuel. Il supporte chaque verbe HTTP standard (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS), accepte des en-têtes arbitraires sous forme JSON propre (tokens Bearer Authorization, X-API-Key, Content-Type, Accept-Language, en-têtes d'entreprise personnalisés), envoie des bodies JSON/XML/form-encoded/raw text, et vous montre tout ce qui revient : code de statut numérique avec la phrase de raison standard, chaque en-tête de réponse analysé et étiqueté, le body pretty-printed s'il parse comme JSON ou gardé brut sinon, le temps aller-retour en millisecondes, et la longueur en octets de la réponse. L'écueil le plus courant pour les tests d'API basés sur navigateur est CORS — les APIs publiques conçues pour usage navigateur (Stripe, GitHub, OpenAI, JSONPlaceholder) fonctionnent bien, mais les APIs internes qui n'attendent que du trafic serveur-à-serveur bloqueront la requête avec un en-tête Access-Control-Allow-Origin manquant. Quand cela arrive, le message d'erreur vous dit exactement quoi chercher dans la configuration CORS de votre serveur API.

Qu'est-ce qu'un testeur de requêtes API ?

Il s'agit d'un client HTTP qui vous permet d'envoyer des requêtes vers un endpoint API et de visualiser la réponse. Utile pour :

- Tester un endpoint durant son développement
- Diagnostiquer une erreur d'API
- Explorer une API tierce
- Vérifier l'authentification
- Tester différentes méthodes HTTP
- Vérifier les formats de réponse

C'est comparable à Postman ou Insomnia mais directement dans le navigateur.

Comment tester une API ?

Procédez ainsi :

1. Renseignez l'URL de l'endpoint
2. Sélectionnez la méthode (GET, POST, PUT, DELETE, PATCH)
3. (Optionnel) Ajoutez des en-têtes JSON
4. (Optionnel) Ajoutez le corps pour POST/PUT/PATCH
5. Cliquez sur "Envoyer la requête"
6. Analysez le statut, les en-têtes, le corps et la durée

Exemple GET :
URL : https://jsonplaceholder.typicode.com/users/1
Méthode : GET

Exemple POST :
URL : https://jsonplaceholder.typicode.com/posts
Méthode : POST
Corps : {"title": "Test", "body": "Contenu", "userId": 1}

Quelles méthodes HTTP sont supportées ?

Toutes les méthodes principales :

- GET : récupérer des données
- POST : créer une ressource
- PUT : remplacer une ressource existante
- PATCH : mise à jour partielle
- DELETE : supprimer une ressource
- HEAD : récupérer uniquement les en-têtes
- OPTIONS : connaître les méthodes autorisées

La plupart des APIs reposent sur GET, POST, PUT/PATCH et DELETE.

Comment ajouter des en-têtes personnalisés ?

Utilisez le format JSON :

{
"Content-Type": "application/json",
"Authorization": "Bearer votre-token",
"X-Custom-Header": "valeur"
}

En-têtes courants :
- Content-Type : format du corps (application/json, text/xml)
- Authorization : Bearer, Basic ou clé API
- Accept : format attendu
- User-Agent : identification du client
- X-API-Key : clé d'API

Les en-têtes sont des paires clé/valeur décrivant la requête.

Que faire en cas d'erreur CORS ?

Le CORS (Cross-Origin Resource Sharing) protège les APIs contre les requêtes provenant d'autres domaines :

- De nombreuses APIs bloquent les requêtes navigateur
- Ce blocage est normal côté sécurité
- Les APIs publiques activent parfois CORS
- Les APIs privées le désactivent souvent

Solutions :
- Utiliser une API compatible CORS
- Tester via une extension qui désactive CORS (uniquement en phase de test)
- Passer par un client côté serveur
- Demander au fournisseur d'activer CORS

Pour les tests poussés, privilégiez Postman, Insomnia ou un run backend.

Quand utiliser PUT vs PATCH vs POST pour mettre à jour une ressource ?

Ces trois verbes semblent interchangeables aux débutants mais ont des sémantiques distinctes qui déterminent la correction de l'API et le comportement du cache. POST CRÉE une NOUVELLE ressource sur le serveur (ou déclenche une action avec effets de bord) — le serveur choisit l'ID de la nouvelle ressource et retourne son emplacement. Utilisez pour /users lors de l'inscription d'un nouvel utilisateur, /orders lors d'une commande, /search lors d'une recherche qui modifie l'état du serveur. PUT REMPLACE une ressource existante entière à une URL connue — vous envoyez la nouvelle représentation complète, et tout champ omis est remis à null/défaut. Utilisez lors de la mise à jour de l'objet profil complet d'un utilisateur à /users/123. PATCH modifie partiellement une ressource existante — vous envoyez uniquement les champs qui changent, en laissant les autres intacts. Utilisez lors du changement uniquement du champ email à /users/123. La spec HTTP dit que PUT et PATCH doivent être IDEMPOTENTS (appeler le même PUT/PATCH deux fois produit le même état final), tandis que POST n'a pas besoin de l'être (deux POSTs à /orders créent deux commandes). Erreur ici et les clients ré-essaieront les POSTs échoués et créeront accidentellement des enregistrements en double.

Comment envoyer un token Bearer Authorization correctement ?

L'authentification Bearer est le pattern d'auth API dominant en 2026 — utilisé par OAuth 2.0, OpenID Connect, les APIs basées sur JWT, et la plupart des plateformes SaaS modernes. Le format est fixé par RFC 6750 : la valeur de l'en-tête Authorization DOIT être le mot littéral 'Bearer' suivi d'exactement un espace et la chaîne du token. Dans le champ Headers de cet outil, collez :

{
"Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U"
}

Erreurs courantes : (1) Oublier l'espace après 'Bearer' — les APIs retournent 401. (2) Utiliser 'bearer' en minuscules — la RFC dit insensible à la casse mais certains serveurs stricts le rejettent. (3) Inclure littéralement les crochets '<' '>' des exemples de documentation dans le token. (4) Envoyer le token brut sans préfixe 'Bearer' — c'est l'ancien pattern Basic auth. (5) Réutiliser un JWT expiré — décodez à jwt.io pour vérifier la claim 'exp'. Ne collez jamais de tokens de production en direct dans des outils non fiables ; ce testeur tourne entièrement dans votre navigateur mais vous devriez quand même faire tourner tout token utilisé pour le débogage une fois terminé.

Que signifient les codes de statut HTTP courants (200, 201, 204, 301, 400, 401, 403, 404, 422, 429, 500, 503) ?

Le code de statut est la première chose à lire dans toute réponse — il vous indique le résultat avant même de regarder le corps.

2xx succès :
- 200 OK : la requête a réussi, le corps contient le résultat.
- 201 Created : un POST a créé une nouvelle ressource ; consultez l'en-tête Location pour son URL.
- 204 No Content : succès avec un corps vide (courant pour DELETE et certains PUT/PATCH).

3xx redirection :
- 301 Moved Permanently : la ressource a une nouvelle URL — mettez à jour votre endpoint.
- 302/307/308 : redirections temporaires ou préservant la méthode.

4xx erreur client (votre requête est incorrecte) :
- 400 Bad Request : syntaxe malformée ou paramètres invalides.
- 401 Unauthorized : authentification manquante ou invalide — vérifiez votre en-tête Authorization / jeton.
- 403 Forbidden : authentifié mais non autorisé (permissions/scopes).
- 404 Not Found : mauvaise URL ou la ressource n'existe pas.
- 422 Unprocessable Entity : le corps a été analysé mais a échoué aux règles de validation.
- 429 Too Many Requests : limite de débit atteinte — patientez et vérifiez l'en-tête Retry-After.

5xx erreur serveur (le serveur a échoué) :
- 500 Internal Server Error : une exception non gérée côté serveur.
- 503 Service Unavailable : serveur surchargé ou en maintenance ; réessayez plus tard.

Règle générale : 4xx signifie corrigez votre requête, 5xx signifie que la faute revient au serveur.

Dois-je définir un en-tête Content-Type lors de l'envoi d'un corps de requête ?

Oui — lorsque vous envoyez un corps, le serveur utilise le Content-Type pour décider comment l'analyser, et se tromper est l'une des causes les plus fréquentes d'une réponse 400 ou 415.

- Corps JSON : définissez Content-Type sur application/json. La plupart des API JSON rejettent ou ignorent silencieusement un corps envoyé sans lui. Le corps doit être un JSON valide, ex. {"name":"Ada"}.
- Données de formulaire : définissez application/x-www-form-urlencoded et envoyez key=value&key2=value2 (le format classique des formulaires HTML).
- Texte brut/XML : utilisez text/plain ou application/xml/text/xml pour que le serveur n'essaie pas de l'analyser comme du JSON.
- Envoi de fichiers : utilisez multipart/form-data (note : les vraies frontières multipart sont plus faciles depuis curl/Postman natif que depuis un champ texte brut).

Pour GET, HEAD, OPTIONS et DELETE sans corps, vous n'avez pas besoin de Content-Type. Rappelez-vous aussi que l'en-tête Accept est le miroir de Content-Type : il indique au serveur le format que vous souhaitez recevoir (ex. Accept: application/json).

Comment fonctionne la fonction Copier en cURL ?

Après avoir envoyé une requête, cliquez sur 'Copier en cURL' pour copier une commande curl prête à l'emploi qui reproduit exactement ce que l'outil vient d'envoyer — même URL, même méthode -X, un drapeau -H par en-tête, et un drapeau --data pour le corps. Collez-la dans n'importe quel terminal, rapport de bug, runbook ou script CI.

C'est la porte de sortie la plus utile hors du navigateur. Comme les navigateurs appliquent CORS, certaines API bloquées dans ce testeur en navigateur fonctionneront parfaitement depuis curl, qui n'a pas de politique de même origine. Donc, quand vous heurtez un mur CORS, convertissez la requête en curl et exécutez-la depuis votre terminal ou serveur pour confirmer que l'API elle-même fonctionne.

La commande générée met des guillemets simples et échappe l'URL, les en-têtes et le corps afin que les valeurs contenant des espaces ou des caractères spéciaux restent intactes. Elle est simple, sans dépendance et portable vers n'importe quel shell, ce qui en fait le format d'échange universel entre ce testeur, vos coéquipiers et votre automatisation.

Mes données sont-elles sécurisées ?

Points de confidentialité :

- Les requêtes partent directement de votre navigateur vers l'API
- Nous ne relayons, ne stockons ni n'inspectons vos données
- Aucun log de vos requêtes ou réponses
- Évitez d'utiliser des identifiants de production
- Privilégiez des environnements de test ou sandbox

Bonnes pratiques :
- Ne partagez pas vos clés API
- Utilisez des credentials dédiés
- Testez avec des données fictives
- Révoquez vos tokens après usage

Fonctionnalités clés

• Tester n'importe quel endpoint REST
• Support complet des méthodes HTTP (GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS)
• Ajout d'en-têtes personnalisés
• Envoi de corps JSON, XML ou texte
• Affichage des codes de statut
• Visualisation des en-têtes de réponse
• Corps de réponse formaté
• Mesure du temps de réponse
• Taille des réponses calculée
• Coloration JSON et copie facile
• Copier toute requête en commande cURL prête à l'emploi
• Mode sombre
• 100% côté client - aucune donnée stockée
• Design responsive utilisable sur mobile