Client / testeur d’API REST

Composez et envoyez des requêtes HTTP avec paramètres de requête, en-têtes, corps JSON ou formulaire et authentification Basic ou Bearer, puis examinez le statut, la durée et les réponses JSON mises en forme. Importez une commande cURL existante, ou copiez la requête courante au format cURL. Vous préférez construire des requêtes réutilisables pas à pas ? Utilisez le Constructeur de requêtes HTTP. Voir aussi la famille Outils API.
Tout s’exécute localement dans votre navigateur. Les requêtes inter-origines sont soumises à la politique CORS du serveur cible — voir la note ci-dessous si une requête échoue.
Paramètres de requête
En-têtes
Corps
Autorisation
Options
Si ce champ est renseigné, l’URL de la requête est ajoutée à ce préfixe. Utile pour les serveurs bloqués par CORS.
200
Corps En-têtes

                                                                
Pourquoi une requête peut échouer : les navigateurs bloquent la lecture inter-origines, sauf si l’API renvoie Access-Control-Allow-Origin. Si la cible n’autorise pas CORS, vous pouvez faire tourner votre propre proxy CORS et coller son URL dans le préfixe de proxy ci-dessus, ou utiliser le convertisseur cURL pour exécuter la requête depuis un terminal. Les corps de requête GET/HEAD sont ignorés, et l’outil WebSocket se trouve à part, sur le Testeur WebSocket.
Les méthodes HTTP expliquées
La méthode que vous choisissez indique au serveur ce que vous voulez faire de l’URL. Voici ce que signifie chacun des sept verbes que cet outil peut envoyer :
GET — récupère une ressource : une page web, une image, une liste d’enregistrements. « Donne-moi ce qui se trouve à cette URL. » Lecture seule et sans effet à répéter, elle ne transporte normalement aucun corps de requête (un corps présent sur une requête GET est ignoré).
POST — envoie de nouvelles données au serveur, en général pour créer une ressource ou déclencher une action — soumettre un formulaire, envoyer un fichier, lancer une tâche. La charge utile voyage dans le corps de la requête. POST n’est pas idempotent : envoyer deux fois le même POST peut créer deux enregistrements.
PUT — remplace la totalité de la ressource située à l’URL par ce que vous envoyez. Le corps doit contenir la version complète et nouvelle de la ressource. PUT est idempotent : répéter la même requête a le même effet que l’envoyer une seule fois.
PATCH — modifie seulement une partie d’une ressource. Vous n’envoyez que les champs à mettre à jour, par ex. {"email": "new@example.com"}, au lieu de l’enregistrement entier. Choisissez PATCH lorsqu’un PUT complet vous obligerait à renvoyer des champs que vous ne modifiez pas.
DELETE — supprime la ressource située à l’URL. DELETE est idempotent : supprimer une ressource déjà absente renvoie le même résultat (en général un 404) et ne fait rien de plus.
HEAD — identique à GET, mais la réponse ne contient que les en-têtes — aucun corps n’est renvoyé. Utilisez HEAD pour vérifier qu’une URL existe, connaître la taille d’un fichier (Content-Length), la date de dernière modification (Last-Modified) ou son type (Content-Type), sans télécharger l’ensemble du contenu.
OPTIONS — demande au serveur quelles méthodes et options sont autorisées pour une URL, ou déclenche une vérification préalable CORS. Les en-têtes de réponse, comme Access-Control-Allow-Methods, listent ce qui est permis. OPTIONS ne transporte généralement pas de corps ; les navigateurs l’envoient souvent automatiquement avant un POST/PUT/PATCH/DELETE inter-origines.
Facile à confondre : HEAD ou GET — la requête est identique, mais HEAD ne renvoie aucun corps. PUT ou PATCH — PUT remplace la ressource entière ; PATCH n’applique une mise à jour partielle qu’aux seuls champs que vous envoyez.