Testez vos APIs REST dans le navigateur : GET, POST, PUT, DELETE, headers custom, body JSON, proxy CORS intégré et réponse formatée avec coloration syntaxique.
Testeur d'API REST en ligne
Saisissez une URL et cliquez sur Envoyer.
Testeur d'API REST : votre Postman dans le navigateur
Les APIs REST sont partout — microservices, services tiers, backends mobiles, intégrations SaaS. Chaque développeur doit pouvoir tester un endpoint en quelques secondes, sans installer Postman, sans configurer un environnement local, sans dépendre d'une connexion VPN. Ce testeur en ligne répond exactement à ce besoin : collez votre URL, sélectionnez votre méthode, ajoutez vos headers et votre body JSON, puis observez la réponse formatée en temps réel.
Qu'est-ce qu'une API REST ?
Une API REST (Representational State Transfer) est une interface de programmation qui expose des ressources via des URLs et les manipule à travers les méthodes du protocole HTTP. Elle repose sur six contraintes architecturales définies par Roy Fielding en 2000 : architecture client-serveur, sans état (stateless), mise en cache, interface uniforme, système en couches et code à la demande (optionnel).
En pratique, une API REST expose des endpoints du type
GET /users, POST /users, PUT /users/42,
DELETE /users/42. Chaque endpoint représente une ressource ou une collection
de ressources, et la méthode HTTP détermine l'opération à effectuer.
| Principe REST | Description | Exemple concret |
|---|---|---|
| Stateless | Chaque requête est indépendante | Token JWT dans chaque header |
| Ressources | Tout est une ressource identifiable | /products/123 |
| Représentations | JSON, XML, HTML selon Accept | Accept: application/json |
| HATEOAS | Liens hypermedia dans les réponses | {"_links": {"self": ...}} |
| Cacheable | Réponses marquables comme cachables | Cache-Control: max-age=3600 |
Méthodes HTTP : GET, POST, PUT, DELETE, PATCH
Les méthodes HTTP sont le verbe de l'opération. Chacune a une sémantique précise définie dans la RFC 7231. Les connaître est indispensable pour concevoir et tester des APIs cohérentes.
- GET — Lire une ressource. Idempotent, sans effet de bord. Aucun body.
- POST — Créer une ressource. Non-idempotent. Body JSON obligatoire.
- PUT — Remplacer une ressource complète. Idempotent. Body complet requis.
- PATCH — Modifier partiellement. Idempotent recommandé. Body partiel.
- DELETE — Supprimer une ressource. Idempotent. Généralement sans body.
- HEAD — Comme GET mais sans corps de réponse. Utile pour vérifier l'existence.
- OPTIONS — Lister les méthodes autorisées sur un endpoint (CORS preflight).
Idempotent signifie que répéter la même requête produit le même résultat. Supprimer 10 fois la même ressource retourne 404 après la première suppression, mais l'état final du serveur est identique : la ressource n'existe plus. GET, PUT, DELETE, HEAD, OPTIONS sont idempotents. POST ne l'est pas (chaque appel crée une nouvelle ressource).
201 Created
avec un header Location: /resources/42 après un POST réussi.
Cela permet au client de connaître l'URL de la ressource créée sans faire un second GET.
Headers HTTP essentiels pour les APIs
Les headers HTTP transportent les métadonnées de la requête et de la réponse. Maîtriser les headers les plus courants vous permet de déboguer rapidement et de configurer correctement vos appels API.
| Header | Sens | Valeur typique |
|---|---|---|
Content-Type | Format du body envoyé | application/json |
Accept | Format attendu en réponse | application/json |
Authorization | Authentification | Bearer eyJhbGci… |
X-API-Key | Clé API | sk-abc123… |
Cache-Control | Politique de cache | no-cache |
X-Request-ID | ID de traçabilité | UUID v4 |
If-None-Match | Cache conditionnel (ETag) | "abc123" |
L'outil permet d'ajouter autant de headers que nécessaire via le panneau
"Headers de requête". Cliquez sur + Ajouter un header, saisissez la clé
(ex : Authorization) et la valeur (ex : Bearer votre_token).
Corps de requête JSON : syntaxe et bonnes pratiques
Pour les requêtes POST, PUT et PATCH, le corps de la requête transporte les données à envoyer au serveur. En REST moderne, JSON (JavaScript Object Notation) est le format universel. Quelques exemples pratiques :
// Création d'un utilisateur (POST /users)
{
"name": "Alice Dupont",
"email": "alice@example.com",
"role": "developer",
"active": true
}
// Mise à jour partielle (PATCH /users/42)
{
"email": "alice.new@example.com"
}
// Création avec relation imbriquée (POST /orders)
{
"customer_id": 42,
"items": [
{ "product_id": 1, "quantity": 3 },
{ "product_id": 7, "quantity": 1 }
],
"shipping_address": {
"street": "12 rue de la Paix",
"city": "Paris",
"zip": "75001"
}
}Content-Type: application/json dans vos headers quand vous envoyez du JSON.
Sans ce header, certaines APIs rejetteront votre requête avec un 415 Unsupported Media Type.
L'outil ajoute ce header par défaut.
Le bouton 🔄 Formater JSON reformate automatiquement votre corps de requête avec une indentation lisible. Il valide également la syntaxe JSON et affiche une alerte si le JSON est malformé.
Authentification API : Bearer, Basic, API Key
La grande majorité des APIs nécessitent une authentification. Les trois mécanismes les plus courants se configurent tous dans les headers de requête.
Bearer Token (JWT / OAuth 2.0)
// Header à ajouter :
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiI0MiIsIm5hbWUiOiJBbGljZSJ9.xxx
// Décodage côté serveur : le token contient user ID, rôles, expiration
// Utilisé par : GitHub API, Stripe, Auth0, Google APIs, la plupart des APIs modernesBasic Authentication
// Username:password encodés en Base64
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
// En JavaScript :
const encoded = btoa('username:password');
// En PHP :
$encoded = base64_encode('username:password');
// Note : TOUJOURS sur HTTPS, jamais en HTTP clairAPI Key dans le header
// OpenAI, SendGrid, Twilio, WeatherAPI…
X-API-Key: sk-proj-abcdefghijklmnop
// Ou dans le header Authorization :
Authorization: ApiKey votre_cle_api
// Ou en query param (moins sécurisé, éviter) :
GET /endpoint?api_key=votre_cleCodes de statut HTTP : comprendre les réponses
Le code de statut HTTP est la première information à lire dans une réponse API. Il indique immédiatement si la requête a réussi, échoué, ou nécessite une action.
| Code | Signification | Contexte typique |
|---|---|---|
| 200 OK | Succès | GET réussi, ressource retournée |
| 201 Created | Ressource créée | POST réussi |
| 204 No Content | Succès sans réponse | DELETE ou PUT sans retour |
| 301 / 302 | Redirection | URL déplacée |
| 304 Not Modified | Cache valide | Réponse servie depuis le cache |
| 400 Bad Request | Requête malformée | JSON invalide, champ manquant |
| 401 Unauthorized | Non authentifié | Token manquant ou expiré |
| 403 Forbidden | Non autorisé | Droits insuffisants |
| 404 Not Found | Ressource introuvable | ID inexistant |
| 422 Unprocessable | Validation échouée | Email invalide, valeur hors plage |
| 429 Too Many Requests | Rate limit atteint | Quota API dépassé |
| 500 Server Error | Erreur serveur | Bug back-end, exception non gérée |
| 503 Unavailable | Service indisponible | Maintenance, overload |
Notre testeur affiche le code de statut avec un badge coloré : 200 OK en vert, 4xx en jaune, 5xx en rouge — pour une lecture instantanée.
Proxy CORS : pourquoi et comment ça fonctionne
CORS (Cross-Origin Resource Sharing) est un mécanisme de sécurité du navigateur
qui bloque par défaut les requêtes JavaScript vers un domaine différent de la page courante.
Concrètement, si votre page est sur angularforall.com et que vous faites un
fetch('https://api.tierce.com/data'), le navigateur vérifie si
api.tierce.com autorise les requêtes cross-origin via ses headers de réponse.
// L'API doit retourner ces headers pour autoriser le cross-origin :
Access-Control-Allow-Origin: https://angularforall.com
// Ou pour tout le monde :
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, AuthorizationSi ces headers sont absents ou restrictifs, le navigateur bloque la requête avec une erreur CORS. Le proxy PHP de cet outil contourne cette limitation : votre navigateur envoie la requête à notre serveur PHP (même origine), qui la relaie côté serveur vers l'API cible, puis retourne la réponse. Côté serveur, il n'y a pas de restriction CORS.
Cas d'usage : tests sans Postman
Voici les situations concrètes où ce testeur en ligne remplace avantageusement Postman ou Insomnia :
- Onboarding rapide : un nouveau développeur teste votre API sans rien installer. Partagez simplement l'URL de cet outil.
- Vérification d'un webhook : envoyez un POST avec le payload exact attendu par votre endpoint pour valider la structure JSON.
- Debug de token JWT : ajoutez votre token Bearer et vérifiez si l'API retourne 200 ou 401 pour isoler un problème d'authentification.
- Test d'APIs publiques : OpenWeatherMap, GitHub API, JSONPlaceholder — explorez les réponses sans quitter le navigateur.
- Formation et tutoriels : montrez en live le fonctionnement des verbes HTTP sans avoir besoin d'un environnement de développement.
- Vérification de déploiement : après un déploiement, tapez quelques endpoints critiques pour valider que le service répond correctement.
// Exemple : tester l'API JSONPlaceholder
GET https://jsonplaceholder.typicode.com/posts/1
// Réponse attendue (200 OK) :
{
"userId": 1,
"id": 1,
"title": "sunt aut facere repellat provident...",
"body": "quia et suscipit\nsuscipit recusandae..."
}
// Créer un post fictif :
POST https://jsonplaceholder.typicode.com/posts
Content-Type: application/json
{
"title": "Mon article de test",
"body": "Contenu du post",
"userId": 1
}
// Réponse (201 Created) :
{
"title": "Mon article de test",
"body": "Contenu du post",
"userId": 1,
"id": 101
}Questions fréquentes
Conclusion
Un testeur d'API REST directement dans le navigateur élimine la friction du onboarding et accélère le débogage. Avec le support des 7 méthodes HTTP, des headers personnalisés, du body JSON formaté, de la coloration syntaxique de la réponse et d'un proxy anti-CORS côté PHP, cet outil couvre 95 % des besoins quotidiens d'un développeur sans rien installer.
Commencez par les presets JSONPlaceholder ou HTTPBin pour vous familiariser, puis testez vos propres APIs. Activez le mode proxy pour les APIs qui ne permettent pas les requêtes cross-origin depuis le navigateur.
