Vérificateur de point de terminaison API

La requête va directement de votre navigateur à l'endpoint, sans passer par notre serveur. Les règles CORS s'appliquent et les cookies sont omis. En mode par étapes, les données restent temporairement dans cet onglet jusqu'au chargement de l'étape 2, puis sont supprimées du stockage de session. L'endpoint reçoit tout de même l'URL, les en-têtes, le corps et votre adresse IP.

Collez une URL HTTP ou HTTPS : l’outil envoie une requête GET, HEAD, POST, PUT, PATCH ou DELETE directement depuis votre navigateur. Il affiche le statut final, le délai jusqu’aux en-têtes, les en-têtes exposés par CORS, l’URL finale après redirection et jusqu’à 1 Mio du corps. L’endpoint doit autoriser l’origine du navigateur via CORS pour que la réponse soit lisible.

Comment vérifier un point de terminaison API

  1. 1

    Entrez l'URL

    Incluez le schéma (http:// ou https://). L'outil suit les redirections par défaut.

  2. 2

    Choisissez la méthode HTTP

    GET est la méthode par défaut. Passez à HEAD pour un contrôle plus léger, POST/PUT/PATCH avec un corps pour tester les points de terminaison d'écriture.

  3. 3

    Ajoutez des en-têtes si nécessaire

    Les en-têtes d'Authorization, Accept, Content-Type et personnalisés peuvent être définis. Utile pour tester l'authentification par clé API ou la négociation de contenu.

  4. 4

    Examinez le résultat visible dans le navigateur

    Examinez le statut final, le délai, les en-têtes exposés par CORS, l'URL finale après redirection et un aperçu du corps limité à 1 Mio.

Référence des codes d’état HTTP

Code Signification Action
200 OK Succès
201 Créé POST/PUT a produit une ressource
204 Pas de contenu Succès sans corps
301 Déplacé de façon permanente Suivre la redirection, mettre à jour les liens
302 Trouvé (redirection temporaire) Suivre la redirection
304 Non modifié Copie mise en cache toujours valide
400 Mauvaise requête Corrigez la requête
401 Non autorisé Identifiants manquants ou invalides
403 Interdit Authentifié mais non autorisé
404 Non trouvé Mauvaise URL ou ressource disparue
429 Trop de requêtes Ralentissez, respectez la limite de taux
500 Erreur interne du serveur Bug du serveur
502 Mauvaise passerelle En amont est hors service
503 Service indisponible Maintenance ou surcharge
504 Délai d’attente de la passerelle En amont n’a pas répondu à temps

Références de temps de réponse

Temps de réponse Perception
Moins de 100 ms Instantané
100-300 ms Rapide
300-1000 ms Acceptable
1-3 secondes Lent, les utilisateurs remarquent
Plus de 3 secondes À examiner pour un usage interactif

Ces plages sont des repères de diagnostic, pas des seuils universels. Si l’API possède un SLA, comparez plusieurs mesures à ses objectifs p95 et p99 publiés.

En-têtes courants à inspecter

  • Content-Type, application/json; charset=utf-8 vs. text/html vous indique ce que vous obtenez réellement.
  • Cache-Control, max-age=3600, public vs. no-store détermine si les caches CDN et navigateur seront utilisés.
  • Access-Control-Allow-Origin, pour le débogage CORS. Doit être * ou explicitement l’origine de la requête.
  • Strict-Transport-Security, La présence de HSTS confirme l’application stricte de HTTPS uniquement.
  • X-RateLimit-Remaining, de nombreuses API publient le quota restant par réponse.

Ce qu’une requête de navigateur ne peut pas révéler

  • Fetch suit les redirections autorisées et indique l’URL finale, mais pas la chaîne complète.
  • Le navigateur valide HTTPS, mais JavaScript ne peut lire ni l’émetteur, ni l’expiration, ni la chaîne du certificat.
  • CORS décide si cette page peut lire le statut, le corps et la plupart des en-têtes. Une erreur CORS ne prouve pas que l’API est indisponible.
  • Le navigateur contrôle notamment Host, Origin, Cookie, Content-Length et User-Agent ; l’outil les refuse au lieu de prétendre les envoyer.

Questions fréquentes

Fetch suit les redirections et expose la réponse et l’URL finales, pas chaque étape. L’outil omet aussi les cookies du navigateur ; une API peut adapter sa réponse aux cookies, à l’origine ou à d’autres en-têtes contrôlés par le navigateur.

Oui, si l’endpoint autorise la requête CORS correspondante. Les valeurs Authorization sont envoyées directement à cet endpoint. En mode par étapes, les champs restent temporairement dans cet onglet jusqu’au chargement de l’étape 2, puis sont supprimés du stockage de session ; ils ne passent jamais par notre serveur. N’utilisez pas de secrets de production avec un endpoint non fiable.

Le chronomètre s’exécute dans votre navigateur, juste avant Fetch et jusqu’à l’arrivée des en-têtes de réponse. Il inclut le navigateur et le réseau, alors que les journaux serveur mesurent souvent le traitement applicatif. Le téléchargement du corps n’est pas inclus ; comparez plusieurs essais avec le même navigateur et le même réseau.

Non. Ce vérificateur utilise Fetch pour des requêtes HTTP et HTTPS ordinaires. WebSocket et gRPC nécessitent des clients adaptés à leur protocole et ne sont pas testés ici.

Outils similaires