Ce qu’est une API

Une API est le moyen pour un programme de demander quelque chose à un autre programme. Le nom vient d’application programming interface (interface de programmation d’application), ce qui en dit très peu. En pratique, et dans la suite de ce tutoriel, une API est un serveur qui répond aux requêtes avec des données plutôt qu’avec des pages web.

Une appli météo sur votre téléphone ne stocke pas les prévisions. Quand vous l’ouvrez, elle envoie une requête à un serveur quelque part, reçoit quelques kilo-octets de températures et de vitesses de vent, et les affiche à l’écran. La partie serveur, c’est l’API. L’appli est l’un de ses clients.

Votre première requête

Collez cette adresse dans la barre d’adresse de votre navigateur et appuyez sur Entrée :

https://api.testingapis.com/api/Products/1

Vous recevez quelque chose comme ceci :

{
  "id": 1,
  "title": "Wireless Noise-Cancelling Headphones",
  "price": 249.99,
  "description": "Over-ear headphones with 30hr battery life and active noise cancellation.",
  "category": "electronics",
  "image": "https://picsum.photos/seed/prod1/400/400",
  "rating": { "rate": 4.3, "count": 127 },
  "inStock": true,
  "createdAt": "2025-06-12T10:30:00Z"
}

Votre navigateur a envoyé une requête à un serveur. Le serveur a cherché le produit numéro 1 et en a renvoyé une description. Cet échange, une requête et une réponse, est ce à quoi se résume toute interaction avec une API. La suite de ce tutoriel porte sur les détails de cet échange, et sur la façon de vérifier que le serveur les respecte.

Vous pouvez aussi envoyer la requête depuis cette page. Le bouton Envoyer ci-dessous fait la même chose que votre navigateur à l’instant, et affiche le statut de la réponse au-dessus du corps. Vous verrez ces boutons tout au long des leçons.

Clients et serveurs

Le programme qui envoie la requête est le client. Le programme qui répond est le serveur. Un client peut être un navigateur, une appli mobile, un autre serveur, un outil en ligne de commande ou un test que vous avez écrit. Le serveur ne fait pas la différence, et n’en a pas besoin. Il lit la requête, fait son travail et répond.

C’est important pour les tests. Comme le serveur traite tous les clients de la même façon, vous pouvez le tester sans l’appli qui lui parle d’habitude. Pas besoin de traverser cinq écrans d’une appli de shopping pour voir si le prix d’un produit est juste. Vous demandez le produit à l’API et vous regardez le prix.

Les points d’accès

L’adresse que vous avez ouverte a deux parties. https://api.testingapis.com est l’URL de base : elle indique à quel serveur parler. /api/Products/1 est le chemin : il indique ce que vous voulez de ce serveur. Chaque chemin que le serveur comprend s’appelle un point d’accès (endpoint). Cette API en a quelques centaines. Quelques exemples :

C’est dans la documentation de l’API que vous découvrez quels points d’accès existent. Pour cette API, c’est la référence de l’API. Les vrais projets varient beaucoup sur ce point. Certains ont une documentation soignée, d’autres un fichier OpenAPI généré à partir du code, et d’autres un message sur un canal de discussion du développeur qui l’a écrite. Une partie du travail de test consiste à remarquer quand la documentation et l’API ne disent pas la même chose.

Quand la réponse est non

Demandez maintenant un produit qui n’existe pas :

Le serveur répond :

{
  "status": 404,
  "error": "Not Found",
  "message": "Product with ID 9999 does not exist."
}

C’est aussi une réponse correcte. Il n’y a pas de produit 9999, et le serveur le dit clairement : un statut 404, qui signifie "introuvable", et un message qui précise quel ID manquait. Une bonne API soigne les requêtes qu’elle ne peut pas satisfaire autant que celles qu’elle peut satisfaire. Une grande partie du test d’API se passe ici, sur le chemin d’erreur, parce que c’est là que les développeurs passent le moins de temps et là que se trouvent la plupart des bugs.

Pourquoi tester au niveau de l’API

Vous pourriez tout tester à travers les écrans de l’appli. Les équipes testent les API directement pour quelques raisons pratiques.

• C’est plus rapide. Une requête prend quelques millisecondes. Atteindre le même état en cliquant dans une interface prend des secondes, et automatiser ces clics est bien plus long à écrire et casse dès qu’un bouton change de place.
• L’API existe généralement en premier. Le backend et le frontend sont souvent construits en parallèle : vous pouvez donc commencer à tester le backend avant qu’il y ait quoi que ce soit sur quoi cliquer.
• L’interface cache des problèmes. Imaginons que le champ quantité d’une appli de shopping n’accepte que les nombres de 1 à 10. L’API derrière reçoit une requête ordinaire, et n’importe qui peut en envoyer une avec une quantité de -5. Si le serveur compte sur l’appli pour avoir vérifié, la commande passe avec un total négatif. Vous ne le découvrez qu’en parlant directement à l’API.
• Une API sert souvent plusieurs clients : un site web, une appli iPhone, une appli Android, une intégration partenaire. Un bug dans l’API est un bug dans chacun d’eux.

Les tests d’interface gardent leur place. Ils sont le seul moyen de vérifier que les écrans fonctionnent. Mais les règles du système (qui peut voir quoi, à quoi ressemble une commande valide, ce qui se passe en rupture de stock) vivent dans l’API, c’est donc là que vous les vérifiez.