Une API permet à un programme de demander une information ou une action à un autre système selon des règles définies. Pour comprendre son fonctionnement, commence par une lecture simple : demander une ressource, examiner la réponse et expliquer ce qui se passe si elle manque. Cet exercice ne nécessite ni paiement ni accès à un compte client.
Le but n’est pas d’ajouter un connecteur à ton site en copiant un exemple. Il est de comprendre les éléments à vérifier avant une intégration. Une requête qui fonctionne une fois ne démontre pas que le parcours est prêt pour les utilisateurs.
Identifier la ressource et la demande
Décris d’abord l’information recherchée : le nom et la disponibilité d’un produit de démonstration, par exemple. Une adresse de ressource indique où la demander. La méthode HTTP exprime le type de demande. Pour cet exercice de lecture, on utilise GET, sans créer de commande ni modifier de fiche.
La documentation du service précise les méthodes disponibles, les paramètres, les droits et la forme des réponses. Ne déduis pas ces règles du seul nom de l’adresse. Une page destinée à être consultée dans un navigateur n’est pas forcément une API documentée.
Prépare une fixture, c’est-à-dire un petit jeu de données de démonstration conservé dans un environnement de test. Il doit être indépendant des comptes réels. Inscris ce que tu attends de la réponse avant d’essayer : un identifiant fictif, un libellé et un état de disponibilité, sans donnée personnelle.
Comprendre les étapes d’une première lecture
Dans un navigateur, la fonction JavaScript fetch permet d’effectuer une requête et d’obtenir une réponse. Consulte la documentation de l’API Fetch sur MDN pour les options et les limites du contexte utilisé.
Lis séparément le statut de la réponse et son contenu. Le statut aide à comprendre comment la demande a été traitée ; le corps contient les données ou un message. Une réponse JSON est un format de données, pas une preuve que ses champs correspondent à ce dont l’application a besoin.
- Vérifier que la réponse correspond à la ressource demandée.
- Examiner le statut avant de traiter le corps.
- Vérifier le format et les champs attendus.
- Afficher un état compréhensible si la donnée n’est pas disponible.
Garde une trace du résultat attendu et observé pour chaque cas. N’affiche pas directement un contenu externe comme du HTML : dans cet exercice, on veut lire des données, pas exécuter ce qu’un service pourrait retourner.
Tester aussi la réponse absente ou incorrecte
Un exercice utile ne se limite pas au chemin réussi. Avec les mêmes données fictives, prévois une ressource présente, une ressource absente, un corps incomplet et une erreur de transport. Ce sont des cas de démonstration, pas des incidents provoqués sur un service public.
fetch ne rejette pas automatiquement sa promesse lorsque le serveur répond avec un statut HTTP d’erreur. Le contrôle du statut reste nécessaire. La lecture du JSON peut également échouer si le corps n’a pas le format attendu. Il faut distinguer ces étapes pour éviter un message de succès trompeur.
Définis la durée pendant laquelle l’interface attend une réponse et le message présenté ensuite. Un chargement sans fin n’explique rien. Conserve la possibilité de revenir à l’écran précédent ou de réessayer la lecture, sans déclencher à la place une autre action.
Séparer ce que voit le navigateur et ce que garde le serveur
Un fichier JavaScript envoyé au navigateur peut être consulté par son utilisateur. Une clé secrète n’a donc pas sa place dans ce fichier. Avant de choisir l’emplacement d’un appel, vérifie si la ressource est publique, si un utilisateur doit être authentifié et quels droits sont nécessaires.
Une lecture publique et un accès à un dossier privé n’ont pas les mêmes exigences. Côté serveur, il faut encore vérifier l’utilisateur et son autorisation sur la ressource demandée. Déplacer un appel sur le serveur ne remplace pas ce contrôle.
Les règles CORS déterminent dans quels cas le navigateur peut accéder à une réponse venant d’une autre origine. Elles ne sont pas une autorisation métier. Si un appel est refusé, examine la documentation et la configuration du service ; ne désactive pas les protections pour faire disparaître l’erreur.
Recevoir un petit exercice avant de connecter le site
Exemple illustratif : la fixture contient une fiche intitulée « Produit de démonstration ». Dans le cas réussi, l’écran affiche son libellé. Dans le cas absent, il indique que la fiche n’est pas disponible. Dans le cas incomplet, il n’invente pas la valeur manquante. Aucun compte, paiement ou email n’est créé.
La réception consiste à comparer ces états aux attentes écrites, avec les outils réellement utilisés. Vérifie aussi que la page reste lisible sur mobile et que le message d’erreur ne remplace pas une valeur par un résultat présenté comme certain.
Ce premier exercice explique une lecture. Pour connecter ensuite une commande, un outil interne ou un accès membre, il faut cadrer le flux complet, les droits, les confirmations et la reprise. Un exemple pédagogique ne doit pas être présenté comme un connecteur prêt pour la production.
Passer de l’exercice à un besoin concret
Liste les informations qui manquent à ton projet : service concerné, documentation disponible, environnement de test, données autorisées et personne responsable des accès. Si une API n’est pas proposée ou ne couvre pas le besoin, cette limite doit apparaître avant le devis.
Une mission d’automatisation peut ensuite définir la connexion utile et ses contrôles. Pour un produit web, le cadrage d’un outil SaaS doit également préciser les utilisateurs et les fonctions nécessaires. Les abonnements et la maintenance sont à identifier séparément.
Tu peux présenter les outils que tu souhaites relier, l’information attendue et ce que tu fais aujourd’hui à la main. Cela permet de discuter d’un périmètre vérifiable, sans promettre une économie automatique ni une connexion disponible avant vérification.
