1. Introduction

1.1 Qu'est-ce que l'API Tester ?

L'API Tester est un outil intégré au site qui permet de tester des API REST directement depuis le navigateur. Il fonctionne de manière similaire à Postman ou Insomnia, mais sans nécessiter l'installation d'un logiciel supplémentaire. Toutes les requêtes sont relayées via un proxy PHP côté serveur (cURL), ce qui permet de contourner les limitations CORS du navigateur.

1.2 Cas d'utilisation

• Tester une API — Vérifier qu'un endpoint répond correctement avec les bons codes de statut et les bonnes données.
• Déboguer un endpoint — Analyser les headers de réponse, les codes d'erreur (4xx, 5xx) et le corps de la réponse pour identifier un problème.
• Vérifier des webhooks — Simuler des appels POST/PUT vers un endpoint de webhook pour valider son comportement.
• Explorer une API tierce — Découvrir les endpoints d'une API publique (JSONPlaceholder, OpenWeatherMap, etc.) avant d'intégrer dans un projet.
• Tester l'authentification — Valider qu'un token Bearer, une clé API ou un Basic Auth fonctionne correctement.

2. Présentation de l'interface

2.1 Vue d'ensemble

L'interface de l'API Tester est divisée en deux zones principales :

Zone de requête (partie haute)

• Sélecteur de méthode — Menu déroulant à gauche permettant de choisir la méthode HTTP (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS). Chaque méthode est affichée avec un code couleur distinctif.
• Barre d'URL — Champ de saisie central où entrer l'URL complète de l'endpoint à tester (ex : https://api.example.com/users).
• Bouton Envoyer — Déclenche l'envoi de la requête. Raccourci clavier : appuyez sur Entrée dans le champ URL.

Onglets de configuration

• Headers — Gestion des en-têtes HTTP personnalisés (clé/valeur avec cases à cocher).
• Body — Configuration du corps de la requête (Raw JSON, Form Data, Texte brut, Aucun).
• Auth — Configuration de l'authentification (Bearer Token, Basic Auth, API Key).
• Historique — Liste des requêtes précédentes, cliquables pour les rejouer.

Zone de réponse (partie basse)

• Barre d'informations — Affiche le code de statut HTTP (coloré), le temps de réponse et la taille.
• Onglet Body — Corps de la réponse (JSON auto-formaté) avec boutons Copier et Formater.
• Onglet Headers — En-têtes de la réponse reçus du serveur.

3. Méthodes HTTP

L'API Tester supporte les 7 méthodes HTTP les plus courantes. Chacune a un rôle spécifique dans l'architecture REST.

3.1 GET — Lire des données

Récupère une ressource sans la modifier. C'est la méthode la plus utilisée. Elle ne possède pas de body.

GET https://jsonplaceholder.typicode.com/posts/1

# Réponse attendue : 200 OK avec le post #1 en JSON

3.2 POST — Créer une ressource

Envoie des données au serveur pour créer une nouvelle ressource. Le body contient généralement du JSON.

POST https://jsonplaceholder.typicode.com/posts

Body (Raw JSON) :
{
  "title": "Mon article",
  "body": "Contenu de l'article",
  "userId": 1
}

# Réponse attendue : 201 Created

3.3 PUT — Remplacer une ressource

Remplace intégralement une ressource existante. Toutes les propriétés doivent être fournies, même celles qui ne changent pas.

PUT https://jsonplaceholder.typicode.com/posts/1

Body (Raw JSON) :
{
  "id": 1,
  "title": "Titre modifié",
  "body": "Nouveau contenu complet",
  "userId": 1
}

# Réponse attendue : 200 OK

3.4 PATCH — Modifier partiellement

Met à jour uniquement les champs spécifiés d'une ressource. Contrairement à PUT, seuls les champs à modifier sont envoyés.

PATCH https://jsonplaceholder.typicode.com/posts/1

Body (Raw JSON) :
{
  "title": "Titre corrigé"
}

# Réponse attendue : 200 OK (seul le titre est modifié)

3.5 DELETE — Supprimer une ressource

Supprime la ressource désignée par l'URL. Ne nécessite généralement pas de body.

DELETE https://jsonplaceholder.typicode.com/posts/1

# Réponse attendue : 200 OK ou 204 No Content

3.6 HEAD — Vérifier sans télécharger

Identique à GET mais ne retourne que les headers, sans le body. Utile pour vérifier l'existence d'une ressource, sa taille ou sa date de modification sans télécharger le contenu.

HEAD https://jsonplaceholder.typicode.com/posts/1

# Réponse : uniquement les headers (Content-Type, Content-Length, etc.)
# Le body sera vide

3.7 OPTIONS — Découvrir les capacités

Interroge le serveur pour connaître les méthodes autorisées sur un endpoint. C'est aussi la requête « preflight » utilisée par les navigateurs pour les requêtes CORS cross-origin.

OPTIONS https://api.example.com/users

# Réponse typique dans les headers :
# Allow: GET, POST, PUT, DELETE, OPTIONS
# Access-Control-Allow-Methods: GET, POST, PUT, DELETE

4. Headers (en-têtes)

4.1 Gestion des headers

L'onglet Headers permet de définir des en-têtes HTTP personnalisés envoyés avec chaque requête. Par défaut, deux headers sont préconfigurés :

• Content-Type: application/json
• Accept: application/json

Ajouter un header

Cliquez sur le bouton + Ajouter un header en bas de la liste. Une nouvelle ligne apparaît avec deux champs (Key et Value) et une case à cocher.

Désactiver temporairement un header

Décochez la case à gauche de la ligne. Le header restera dans la liste mais ne sera pas envoyé avec la requête. C'est utile pour tester avec et sans un header spécifique.

Supprimer un header

Cliquez sur le bouton × à droite de la ligne pour la supprimer définitivement.

4.2 Headers courants

Header	Valeur courante	Description
Content-Type	application/json	Format du body envoyé (JSON, form-data, text, etc.)
Accept	application/json	Format de réponse souhaité
Authorization	Bearer eyJhbG...	Token d'authentification (géré automatiquement via l'onglet Auth)
Cache-Control	no-cache	Contrôle du cache — utile pour forcer des réponses fraîches
User-Agent	CustomAgent/1.0	Identifier le client — certaines API filtrent par User-Agent
X-Custom-Header	valeur	Headers personnalisés spécifiques à votre API

4.3 Exemples pratiques

Forcer une réponse XML

Accept: application/xml

Envoyer du form-urlencoded

Content-Type: application/x-www-form-urlencoded

Ajouter un header CORS personnalisé

Origin: https://monsite.example.com

5. Body (corps de requête)

L'onglet Body permet de définir le contenu envoyé avec les requêtes POST, PUT et PATCH. Quatre types de body sont disponibles :

5.1 Raw JSON

Le mode par défaut. Saisissez du JSON brut dans la zone de texte. Le header Content-Type: application/json est envoyé automatiquement.

{
  "username": "admin",
  "email": "admin@example.com",
  "role": "administrator",
  "permissions": ["read", "write", "delete"]
}

Bouton Formater JSON

Cliquez sur le bouton { } Formater JSON sous la zone de texte pour auto-indenter votre JSON. Cela permet de :

• Corriger l'indentation d'un JSON collé en une seule ligne
• Vérifier la validité syntaxique — si le JSON est invalide, un message d'erreur s'affiche
• Améliorer la lisibilité avant l'envoi

5.2 Form Data

Utilisé pour envoyer des données sous forme de paires clé/valeur, comme un formulaire HTML classique. Le Content-Type sera application/x-www-form-urlencoded.

Ajoutez des champs avec le bouton + Ajouter et remplissez les clés et valeurs :

Key: username     Value: admin
Key: password     Value: s3cret
Key: remember     Value: true

Quand l'utiliser : API legacy qui n'acceptent pas le JSON, endpoints d'authentification par formulaire, APIs qui attendent du application/x-www-form-urlencoded.

5.3 Texte brut (Plain Text)

Envoie le contenu tel quel sans formatage. Le Content-Type sera text/plain.

Ceci est un message en texte brut.
Il peut contenir plusieurs lignes.
Aucun formatage JSON n'est appliqué.

Quand l'utiliser : Envoi de données CSV, logs, ou tout contenu non structuré.

5.4 Aucun (None)

Aucun body n'est envoyé avec la requête. C'est le mode à utiliser pour les requêtes GET, DELETE, HEAD et OPTIONS qui n'ont généralement pas besoin de body.

6. Authentification

L'onglet Auth permet de configurer l'authentification sans manipuler manuellement les headers. Trois méthodes sont supportées en plus du mode « Aucune ».

6.1 Bearer Token

Ajoute automatiquement le header Authorization: Bearer <token>. C'est le type d'authentification le plus répandu pour les API modernes.

Cas d'utilisation

• JWT (JSON Web Token) — Token généré après une connexion (login), utilisé pour accéder aux endpoints protégés.
• OAuth2 — Token obtenu via un flux d'autorisation (Google, GitHub, Azure AD, etc.).
• Personal Access Token — Token généré manuellement (GitHub, GitLab, Jira, etc.).

Comment l'utiliser

1. Dans l'onglet Auth, sélectionnez Bearer Token
2. Collez votre token dans le champ (ex : eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...)
3. Envoyez la requête — le header Authorization: Bearer eyJhbG... sera ajouté automatiquement

# Header généré automatiquement :
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U

6.2 Basic Auth

Envoie un nom d'utilisateur et un mot de passe encodés en Base64 dans le header Authorization. Méthode ancienne mais encore utilisée par de nombreuses API internes et services.

Comment l'utiliser

1. Sélectionnez Basic Auth dans l'onglet Auth
2. Remplissez les champs Utilisateur et Mot de passe
3. L'outil encode automatiquement en Base64 et ajoute le header

# Pour utilisateur "admin" et mot de passe "secret123" :
# Encodage Base64 de "admin:secret123" = YWRtaW46c2VjcmV0MTIz

Authorization: Basic YWRtaW46c2VjcmV0MTIz

6.3 API Key

Envoie une clé d'API dans un header personnalisé. Le nom du header est configurable (par défaut X-API-Key).

Comment l'utiliser

1. Sélectionnez API Key dans l'onglet Auth
2. Définissez le Nom du header (ex : X-API-Key, api-key, x-functions-key)
3. Collez la Valeur de votre clé

# Exemples de headers générés selon le service :
X-API-Key: abc123def456ghi789
api-key: sk-proj-xxxxxxxxxxxxxxxxx
x-functions-key: HostKey_xxxxxxxx

Services courants utilisant des API Keys

• OpenAI — Header Authorization: Bearer sk-... (utiliser Bearer Token)
• Azure Functions — Header x-functions-key
• SendGrid — Header Authorization: Bearer SG.xxx
• APIs internes — Souvent X-API-Key ou api-key

7. Lecture de la réponse

Après l'envoi d'une requête, la zone de réponse apparaît en bas de l'interface avec plusieurs informations clés.

7.1 Code de statut HTTP

Le code de statut est affiché avec un code couleur pour une identification rapide :

Plage	Couleur	Signification	Exemples courants
2xx	● Vert	Succès	200 OK, 201 Created, 204 No Content
3xx	● Bleu	Redirection	301 Moved Permanently, 302 Found, 304 Not Modified
4xx	● Orange	Erreur client	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
5xx	● Rouge	Erreur serveur	500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

7.2 Durée et taille

• Temps — Durée de la requête en millisecondes (ms). Inclut le temps de transit via le proxy PHP. Un temps inférieur à 500ms est généralement bon.
• Taille — Taille du body de la réponse en octets, Ko ou Mo. Utile pour identifier des réponses anormalement volumineuses.

7.3 Body de la réponse

Le corps de la réponse est affiché dans l'onglet Body de la zone réponse. Si la réponse est du JSON, elle est automatiquement formatée avec indentation pour une lecture facile.

Bouton Copier

Copie intégralement le body de la réponse dans le presse-papier. Pratique pour coller le résultat dans un éditeur ou le partager.

Bouton Formater

Force le re-formatage du JSON de la réponse avec une indentation propre. Utile si la réponse est arrivée en JSON compact (sur une seule ligne).

7.4 Headers de la réponse

L'onglet Headers de la zone réponse affiche tous les en-têtes retournés par le serveur. Parmi les plus utiles :

• Content-Type — Le format de la réponse (JSON, HTML, XML, etc.)
• Content-Length — Taille de la réponse en octets
• Cache-Control — Politique de mise en cache
• X-RateLimit-* — Limites de requêtes (quotas API)
• Access-Control-Allow-* — Headers CORS (origines, méthodes autorisées)
• Set-Cookie — Cookies définis par le serveur

8. Historique

8.1 Fonctionnement

Chaque requête envoyée est automatiquement sauvegardée dans l'historique. L'onglet Historique affiche la liste des dernières requêtes avec :

• La méthode HTTP (avec son code couleur : GET en vert, POST en orange, etc.)
• L'URL de l'endpoint appelé
• Le code de statut de la réponse

8.2 Rejouer une requête

Cliquez sur n'importe quelle entrée de l'historique pour recharger automatiquement tous les paramètres de la requête :

• La méthode HTTP
• L'URL
• Les headers
• Le body
• La configuration d'authentification

Il suffit ensuite de cliquer sur Envoyer (ou appuyer sur Entrée) pour relancer la requête.

8.3 Stockage et limites

• Stockage — L'historique est sauvegardé dans le localStorage du navigateur. Il persiste entre les sessions et les rechargements de page.
• Limite — Maximum 50 entrées. Lorsque la limite est atteinte, la requête la plus ancienne est automatiquement supprimée pour faire place à la nouvelle.
• Portée — L'historique est propre à chaque navigateur et à chaque profil. Changer de navigateur ou vider les données du site supprime l'historique.

8.4 Vider l'historique

Cliquez sur le bouton Vider l'historique en bas de l'onglet Historique pour supprimer toutes les entrées. Cette action est irréversible.

9. Cas pratiques

9.1 GET sur une API publique

Testez rapidement l'outil avec l'API gratuite JSONPlaceholder :

1. Méthode : GET
2. URL : https://jsonplaceholder.typicode.com/users
3. Cliquez sur Envoyer

Résultat attendu :

# Status : 200 OK (vert)
# Body : tableau JSON de 10 utilisateurs

[
  {
    "id": 1,
    "name": "Leanne Graham",
    "username": "Bret",
    "email": "Sincere@april.biz",
    "address": {
      "street": "Kulas Light",
      "suite": "Apt. 556",
      "city": "Gwenborough"
    }
  },
  ...
]

9.2 POST avec body JSON

Créez une nouvelle ressource avec un body JSON :

1. Méthode : POST
2. URL : https://jsonplaceholder.typicode.com/posts
3. Onglet Body → Raw JSON
4. Saisissez le body ci-dessous
5. Vérifiez que les headers Content-Type: application/json et Accept: application/json sont activés
6. Cliquez sur Envoyer

{
  "title": "Test depuis API Tester",
  "body": "Ceci est un article créé via l'outil API Tester.",
  "userId": 1
}

Résultat attendu :

# Status : 201 Created (vert)
# Body :
{
  "title": "Test depuis API Tester",
  "body": "Ceci est un article créé via l'outil API Tester.",
  "userId": 1,
  "id": 101
}

9.3 Requête avec Bearer Token

Exemple pour appeler une API protégée par JWT :

1. Méthode : GET
2. URL : https://api.example.com/me/profile
3. Onglet Auth → Bearer Token
4. Collez votre token JWT dans le champ Token
5. Cliquez sur Envoyer

# Header envoyé automatiquement :
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

# Si le token est valide :   200 OK + données du profil
# Si le token est expiré :  401 Unauthorized
# Si le token est invalide : 403 Forbidden

9.4 Déboguer une erreur 404 / 500

Étapes de débogage lorsqu'une requête retourne un code d'erreur :

Erreur 404 (Not Found)

1. Vérifiez l'URL — une faute de frappe est la cause la plus courante
2. Vérifiez la méthode HTTP — certains endpoints n'acceptent que POST, pas GET
3. Vérifiez les trailing slashes — /api/users vs /api/users/
4. Consultez le body de la réponse — certaines API renvoient un message d'erreur détaillé

# Exemple de réponse 404 :
{
  "error": "Not Found",
  "message": "L'endpoint /api/usr n'existe pas. Vouliez-vous dire /api/users ?"
}

Erreur 500 (Internal Server Error)

1. Vérifiez le body envoyé — un JSON malformé peut causer une erreur côté serveur
2. Utilisez le bouton Formater JSON pour valider la syntaxe du body
3. Vérifiez les headers — un Content-Type manquant ou incorrect peut causer une erreur 500
4. Consultez le body de la réponse pour le message d'erreur serveur
5. Essayez avec un body minimal pour isoler le problème

9.5 Tester les headers CORS

Pour vérifier la configuration CORS d'une API :

1. Méthode : OPTIONS
2. URL : l'endpoint à tester
3. Ajoutez le header : Origin: https://votre-domaine.com
4. Envoyez la requête
5. Consultez les headers de réponse (onglet Headers dans la zone réponse)

# Headers CORS à vérifier dans la réponse :
Access-Control-Allow-Origin: https://votre-domaine.com  (ou *)
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

10. Bonnes pratiques et limites

10.1 Bonnes pratiques

Sécurité des tokens

• Ne testez jamais des tokens de production sur un poste non sécurisé
• Videz l'historique après avoir testé des API avec authentification, surtout sur un poste partagé
• Utilisez des tokens de développement ou de test quand c'est possible
• Rappelez-vous que l'historique (incluant les tokens) est stocké en clair dans le localStorage

Optimisation des tests

• Commencez toujours par un GET simple pour vérifier que l'API répond
• Utilisez le bouton Formater JSON avant d'envoyer pour détecter les erreurs de syntaxe
• Consultez les headers de réponse pour comprendre les limites de l'API (rate limits, pagination)
• Utilisez l'historique pour rejouer rapidement des requêtes précédentes

Débogage efficace

• Vérifiez toujours le code de statut en premier — il oriente immédiatement vers le type de problème
• Lisez le body de la réponse en cas d'erreur — la plupart des API y incluent un message explicatif
• Comparez les headers envoyés avec la documentation de l'API
• Testez en réduisant progressivement la complexité (retirez les headers, simplifiez le body) pour isoler le problème

10.2 Limites de l'outil

Proxy PHP

Toutes les requêtes transitent par le fichier api/api-tester.php côté serveur. Cela signifie :

• Le temps mesuré inclut le transit navigateur → serveur PHP → API cible → serveur PHP → navigateur. Il est donc légèrement supérieur au temps réel de l'API.
• Les API uniquement accessibles depuis le réseau local du serveur PHP peuvent être testées (avantage), mais les API restreintes par IP source vérifieront l'IP du serveur, pas celle de votre poste.
• Les fichiers volumineux (upload/download) peuvent être limités par la configuration PHP du serveur (upload_max_filesize, post_max_size, max_execution_time).

Timeout

Si une API met trop de temps à répondre, la requête peut être interrompue par le timeout du serveur PHP ou du proxy. Si vous obtenez un timeout :

• Vérifiez que l'URL est correcte et que l'API est accessible
• Essayez un endpoint plus léger (ex : /health ou /ping)
• Les API très lentes (traitement long, génération de rapports) ne sont pas adaptées à cet outil

Réponses volumineuses

Les réponses très volumineuses (plusieurs Mo) peuvent ralentir l'affichage dans le navigateur. Si la réponse est trop grande :

• Utilisez des paramètres de pagination (?page=1&limit=10) pour limiter les résultats
• Filtrez les champs retournés si l'API le supporte (?fields=id,name)
• Le bouton Formater sur une réponse très volumineuse peut temporairement bloquer l'interface

Limitations liées au navigateur

• L'upload de fichiers n'est pas supporté (pas de multipart/form-data avec fichiers)
• Les requêtes WebSocket ne sont pas supportées — l'outil est conçu pour HTTP/HTTPS uniquement
• Les certificats clients (mTLS) ne sont pas configurable depuis l'interface