Comment utiliser cette liste d'API publiques
Choisissez une API et une compétence. Écrivez trois cas : le cas nominal, un cas limite, et un cas où vous attendez un échec et vérifiez que cet échec a bien la forme attendue. Le troisième est celui que la plupart des gens sautent, et c'est lui qui distingue une suite qui détecte des bugs d'une suite qui confirme que le service est en ligne.
Une remarque avant de commencer. Ce sont des services partagés, maintenus par des bénévoles ou offerts par des entreprises à titre gracieux. Limitez votre volume d'appels, ne dirigez pas de générateur de charge vers eux, et mettez les réponses en cache quand vous le pouvez.
Pour apprendre les bases des requêtes et des réponses
JSONPlaceholder. Une fausse API REST avec des posts, des commentaires, des utilisateurs et des todos. Elle accepte les écritures et fait comme si elle les enregistrait. À travailler : les verbes CRUD, les codes de statut, et la différence entre une requête qui a réussi et une modification qui a bien été enregistrée. Comme les écritures ne sont pas réellement sauvegardées, c'est une leçon particulièrement efficace pour apprendre à écrire des assertions sur les résultats plutôt que sur les réponses.
HTTPBin. Un endpoint qui vous renvoie tout ce que vous lui envoyez, plus des routes qui retournent n'importe quel code de statut demandé, qui temporisent volontairement ou qui renvoient des payloads malformés. À travailler : les timeouts, les relances, la gestion des redirections et le comportement des en-têtes. Si vous voulez voir comment votre suite réagit à un 503, vous pouvez en provoquer un à la demande.
REST Countries. Des données sur les pays, avec une structure stable et bien documentée, sans clé requise. À travailler : les assertions de schéma et la validation champ par champ sur un payload assez gros pour être intéressant mais assez petit pour être lu.
Pour la pagination et les grandes collections
PokéAPI
Un grand jeu de données fortement interconnecté, avec une pagination classique par offset et limit.
À travailler : le parcours des pages, la vérification qu'un parcours complet renvoie bien le nombre d'éléments annoncé par la collection, et la détection des erreurs de décalage d'une unité aux limites de page.
Open Library
Des fiches de livres et d'auteurs avec une recherche, et beaucoup d'enregistrements aux champs manquants ou incohérents.
À travailler : la tolérance aux champs optionnels. Les données réelles sont désordonnées, et une suite qui suppose que chaque enregistrement est complet cassera au contact de la production.
GitHub REST API
Fonctionne sans authentification à faible volume, et avec authentification via un token.
À travailler : la pagination par en-tête Link, les requêtes conditionnelles, et la différence de comportement avant et après authentification.
Pour l'authentification et les limites de débit
GitHub, en mode authentifié
À travailler : la gestion des tokens, les erreurs de portée, et la vérification qu'une requête sans permission échoue de la bonne manière plutôt que de façon générique.
Open-Meteo
Des prévisions météo, sans clé, avec une politique d'usage raisonnable publiée.
À travailler : les combinaisons de paramètres de requête et les données temporelles, dont la bonne réponse change d'une exécution à l'autre. Un bon entraînement pour les assertions qui ne peuvent pas être des correspondances exactes.
HTTPBin, encore
À travailler : les flux d'authentification basique et par token bearer, sur des endpoints conçus exactement pour cela, sans risquer d'épuiser le quota de quelqu'un d'autre.
Trois assertions à travailler sur n'importe quelle API publique
Quel que soit le service choisi, ce sont ces réflexes qui se transposeront à votre propre API.
Vérifiez le corps de la réponse, pas seulement le statut. Un 200 qui transporte une liste vide là où un enregistrement devrait se trouver est un bug qu'une assertion sur le code de statut validera sans sourciller. Ce seul réflexe détecte plus de défauts réels que n'importe quel autre.
Vérifiez que les échecs échouent correctement. Demandez quelque chose qui n'existe pas et vérifiez que vous obtenez le bon code et une structure d'erreur exploitable. Les services qui renvoient un 200 contenant un objet d'erreur sont courants, et une suite qui l'ignore restera verte indéfiniment.
Vérifiez les relations, pas seulement les champs. Si un post référence un utilisateur, récupérez cet utilisateur et vérifiez qu'il existe. Les bugs les plus intéressants se logent entre deux endpoints plutôt qu'à l'intérieur d'un seul.
Diriger un agent vers l'une d'elles
Si vous voulez voir à quoi ressemble une couverture générée avant de l'essayer sur votre propre service, une API publique est un terrain sans risque. Il n'y a aucune donnée à polluer ni aucun environnement à casser.
Dirigez un projet vers l'URL de base et laissez la découverte énumérer les endpoints, puis lisez le plan généré avant de lancer quoi que ce soit. C'est le plan qui est intéressant. Deux choses méritent votre attention au passage.
Capture-t-il les valeurs au lieu de les coder en dur ? Un appel de création renvoie un identifiant, et l'appel suivant devrait l'utiliser. Les identifiants codés en dur sont la raison habituelle pour laquelle une suite ne fonctionne qu'une seule fois.
Ordonne-t-il correctement les appels dépendants ? Vous ne pouvez pas récupérer un commentaire sur un post qui n'a jamais été créé. Regardez si le plan le comprend ou s'il se contente de lister les endpoints par ordre alphabétique.
Lancez-le ensuite et lisez les échecs. Sur une API publique, la plupart des échecs viendront de vos hypothèses plutôt que du service, et c'est précisément la leçon à retenir.
Si vous préférez maîtriser le code de test, le CLI emprunte une autre voie pour le backend : vous écrivez vous-même les appels et les assertions en Python, vous déclarez ce que chaque test consomme et produit, et vous marquez le nettoyage comme un test à part entière. C'est plus de travail au départ, et cela place la suite dans votre dépôt, ce que certaines équipes veulent et d'autres non.
Passer de l'entraînement à votre propre service
L'écart entre s'entraîner sur une API publique et tester la vôtre est plus grand qu'il n'y paraît, et savoir où la difficulté augmente vous épargnera quelques frustrations.
De votre point de vue, les API publiques sont sans état : vous lisez, et ce que vous écrivez ne persiste pas ou n'a pas d'importance. Votre propre service, c'est l'inverse. Dès que vous testez quelque chose de réel, vous héritez d'une authentification qui expire, d'enregistrements qui doivent exister avant d'autres enregistrements, de valeurs qui n'existent qu'à l'exécution, et de l'obligation de faire le ménage derrière vous.
Rien de tout cela n'apparaît dans un tutoriel, et tout cela apparaît dès la première semaine. Considérez donc la phase « API publique » comme l'apprentissage des assertions, qui se transpose intégralement, et attendez-vous à ce que la gestion de l'état soit un apprentissage distinct, à mener ensuite, plutôt que le prolongement de la même compétence.
Ce qu'il ne faut pas faire avec ces API
Ne les utilisez pas pour des tests de charge. Elles sont gratuites, partagées, et quelqu'un en paie la facture.
N'en faites pas une dépendance de production. Les conditions changent, les projets finissent archivés, et les bénévoles se lassent.
Ne prenez pas une suite qui passe sur JSONPlaceholder pour la preuve que votre propre API est correcte. Cela vous dit que votre dispositif de test fonctionne, ce qui est réellement utile mais bien plus modeste.
Essayer sur un vrai service
Une fois les réflexes d'assertion bien installés, c'est au moment de passer à votre propre API que les problèmes d'état commencent, et c'est cette partie que TestSprite prend en charge en tant que produit. Auto-Authentication maintient les sessions actives pendant toute une exécution. Dynamic Variables transporte un identifiant d'un appel de création jusqu'à l'appel de suppression. Dependency Chains détermine ce qui doit se produire en premier. Auto-Cleanup supprime ce que l'exécution a créé.
Démarrer sur votre propre service ressemble à l'exercice sur API publique décrit plus haut : vous dirigez un projet vers l'URL de base, vous laissez la découverte énumérer les endpoints, et vous lisez le plan généré avant toute exécution. La différence, c'est que le plan couvre désormais l'autorisation et les cas limites, et que l'exécution ne laisse rien derrière elle.
C'est sans risque de l'essayer d'abord sur une API publique, puisqu'il n'y a aucune donnée à polluer, et le plan vous en apprendra plus sur l'outil que les résultats.
Par laquelle commencer ?
JSONPlaceholder pour la première heure, parce que rien ne peut mal tourner. HTTPBin ensuite, parce qu'il vous permet de provoquer des échecs volontairement, et c'est en travaillant les échecs que l'on apprend.
Certaines de ces API nécessitent-elles une clé d'API ?
La plupart de celles de cette liste fonctionnent sans clé. GitHub fonctionne sans authentification à faible volume, et obtenir un token vaut la peine précisément parce que cela vous permet de travailler les flux authentifiés.
Puis-je les utiliser dans un pipeline CI ?
Pour une petite suite d'apprentissage, oui. Pour tout ce qui s'exécute à chaque commit, passez plutôt par un mock local. Diriger votre CI vers un service tenu par des bénévoles, c'est exactement ainsi qu'une ressource gratuite et utile cesse d'être gratuite.
En quoi est-ce différent d'une collection Postman d'API publiques ?
Une collection vous donne des requêtes. Cette liste est organisée autour de ce que chaque service vous apprend, ce qui compte davantage quand l'objectif est de progresser en test plutôt que de faire aboutir un appel.
Quel est le moyen le plus rapide de voir une couverture générée ?
Dirigez un projet vers une URL de base publique, laissez la découverte énumérer les endpoints, et lisez le plan avant de lancer quoi que ce soit. Le plan vous en apprend plus sur l'outil que les résultats.
Choisissez une API, travaillez une compétence, écrivez toujours le cas qui échoue.
Les API publiques sont l'endroit le plus sûr pour apprendre à quoi ressemble une bonne couverture, parce qu'il n'y a rien à casser. Le moment venu, appliquez la même approche à votre propre service et gardez le réflexe de vérifier les corps de réponse, les échecs et les relations.