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é.

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
• Mode sombre
• 100% côté client - aucune donnée stockée
• Design responsive utilisable sur mobile