Guide débutant sur les API

Vous avez peut-être déjà croisé l’abréviation “API” des dizaines de fois. Si vous avez déjà payé en ligne ou utilisé un agrégateur de données, vous avez déjà eu recours à une API, sans forcément le savoir. Mais de quoi s’agit-il ? Dans cet article, nous expliquons ce que sont les API, les protocoles qu’elles utilisent et les différents types d’API.

Qu’est-ce qu’une API et comment fonctionne-t-elle ?

Une interface de programmation d’application est une interface logicielle qui permet à différentes applications de communiquer entre elles. Les API interviennent principalement dans le backend des systèmes : leur fonctionnement est donc invisible, et vous ignorez souvent que vous en utilisez une à cet instant précis.

Vous consultez votre site d’actualités préféré et y trouvez les prévisions météo du jour. D’autres sites similaires vous proposent sans doute les mêmes informations. Mais d’où viennent ces données ? Les rédactions ne disposent évidemment pas de leurs propres stations météo pour établir leurs prévisions : elles les obtiennent auprès d’un service météorologique. Le site doit toutefois vous fournir des prévisions précises et pertinentes pour votre position, alors que des milliers de visiteurs, répartis dans de nombreux lieux, le consultent au même moment. Les développeurs ou administrateurs du site ne peuvent pas fournir ni mettre à jour manuellement les prévisions de chaque visiteur. Ils utilisent donc une API. Chaque fois que vous ouvrez ce site pour lire les actualités, il utilise une API pour “appeler” une application météo, connaître la météo à votre position et afficher sa réponse. C’est un peu comme composer le numéro d’un ami pour le joindre : une API est l’équivalent du “numéro de téléphone” que les applications utilisent pour communiquer.

Les API sont populaires et très utilisées pour de bonnes raisons. Elles simplifient d’abord le développement : les développeurs n’ont pas à réinventer la roue et peuvent réutiliser la même API dans de nombreux projets. Le développement est ainsi plus rapide, ce qui fait gagner du temps et réduit les coûts. Grâce aux API, les applications n’interfèrent pas avec leurs processus respectifs ; elles obtiennent uniquement les données nécessaires. Cela renforce la sécurité, réduit le risque d’erreur et contribue au bon fonctionnement des logiciels.

Les API permettent aussi à des systèmes différents de communiquer, quelles que soient les technologies et architectures qui les sous-tendent. Pour les utilisateurs, elles ouvrent l’accès à un large éventail de fonctionnalités.

Lorsque nous parlons d’API, nous faisons principalement référence aux API web, c’est-à-dire à celles qui nécessitent une connexion Internet. Certaines API sont toutefois utilisées au sein d’un même système ou sur un même appareil, par exemple dans le système d’exploitation d’un ordinateur, et n’ont jamais besoin d’une connexion Internet. Dans cet article, nous nous concentrons sur les API web.

Composants des API

Regardons maintenant ce qui se passe en coulisses. De quels éléments se compose une API ?

Le principe fondamental de toute API est l’interopérabilité. Autrement dit, toute plateforme qui prend en charge le format choisi doit pouvoir interagir avec l’API de la même manière. Ainsi, quels que soient les développeurs ou les protocoles utilisés, les composants essentiels des API restent les mêmes.

Client API

Un client API est toute application, navigateur ou logiciel qui effectue des requêtes. Différents éléments peuvent déclencher l’envoi d’une requête par un client. Par exemple, une action de l’utilisateur, comme l’actualisation d’une page ou l’appui sur un bouton, peut en déclencher une. Des événements survenant côté backend et reposant sur une logique automatisée, comme des requêtes de base de données, peuvent également servir de déclencheurs.

Requête API

Les requêtes API doivent suivre la même norme. Elles contiennent généralement cinq éléments principaux :

Endpoints

Dans le contexte des API, les endpoints sont les URL vers lesquelles vous dirigez vos requêtes. Pour savoir quels endpoints sont disponibles et quel format utiliser, vous devez consulter attentivement la documentation de l’API, où le fournisseur de l’API précise tous les détails. En règle générale, les endpoints comprennent le nom de domaine et la version de l’API utilisée. Ils peuvent également contenir divers paramètres de requête. Là encore, la documentation de l’API fournit des informations sur les paramètres disponibles.

Méthode

Dans votre requête, vous devez indiquer à un serveur ce que vous voulez qu’il fasse. Une méthode est donc une commande destinée à un serveur, qui lui indique quoi faire. Les méthodes diffèrent selon le protocole d’API utilisé. Par exemple, le protocole REST s’appuie sur des méthodes HTTP telles que GET, POST, PUT, PATCH et DELETE. D’autres protocoles ont leurs propres méthodes. Si vous comptez utiliser une API, lisez sa documentation, où le fournisseur précise le protocole et les méthodes utilisés par cette API particulière.

Paramètres

En plus des paramètres de requête, il existe également des paramètres de chemin, des paramètres d’en-tête et des paramètres de corps de requête. Ils sont nécessaires pour l’authentification, le filtrage de votre requête et la transmission des détails nécessaires à un serveur destinataire. Alors que la méthode indique au serveur quoi faire, par exemple récupérer des données, les paramètres aident à préciser ce qu’il doit vous transmettre.

En-têtes

Les en-têtes d’une requête API remplissent un rôle classique : ils fournissent des données supplémentaires sur la requête et les formats de réponse souhaités, des détails d’autorisation pour prouver que vous êtes autorisé à effectuer les actions demandées, ainsi que des détails sur la mise en cache des requêtes et des réponses.

Corps de la requête

C’est le cœur de vos requêtes, où vous fournissez toutes les données principales à l’aide des paramètres de requête. Pour mieux le comprendre, imaginez un colis. Les endpoints correspondent à l’endroit où vous voulez que votre colis soit expédié. Les paramètres et les en-têtes sont d’autres données d’envoi, comme le nom et le numéro de téléphone du destinataire, avec des détails supplémentaires, par exemple si votre colis contient des objets fragiles ou si la livraison est payée ou doit être payée par le destinataire. Le corps de la requête est comme un colis, le contenu de la boîte, les objets que vous envoyez. Comme mentionné, le corps de la requête contient différents paramètres que le fournisseur de l’API précise dans la documentation.

Serveur API

Un serveur API est une plateforme, un logiciel, une base de données ou tout autre élément auquel nous envoyons nos requêtes. Il fournit l’API, stocke toutes les données de l’API et exécute les actions que nous précisons dans nos requêtes.

Réponse API

Lorsqu’il y a une requête, il y a aussi une réponse. Une réponse est ce qu’un serveur envoie à la suite de votre requête. Les réponses se composent également de plusieurs éléments constitutifs.

Code d’état

Le code d’état indique si notre requête a abouti et si un serveur a pu la traiter. Les codes en 200 signifient qu’une requête a réussi, les 300 indiquent une redirection, les 400 impliquent qu’il y a eu des problèmes avec une requête, et les 500 signifient qu’il y a eu un problème côté serveur.

En-têtes de réponse

Les en-têtes de réponse sont similaires aux en-têtes de requête. Ils envoient des cookies à un client et fournissent des détails sur le corps de la réponse.

Corps de la réponse

Le corps de la réponse comprend une série de paires clé/valeur qui fournissent les données demandées. Le corps de la réponse n’est toutefois pas indispensable. Si vous demandez à un serveur de récupérer certaines données et de vous les envoyer, la réponse en contiendra un. En revanche, si vous supprimez ou remplacez des données sur un serveur, vous n’obtiendrez généralement qu’un code d’état.

Protocoles d’API

Un protocole est un ensemble de règles définissant le fonctionnement d’une API. Plusieurs protocoles sont utilisés pour les API.

REST

REST (ou RESTful, Representational State Transfer) est le style d’API le plus répandu. Il s’agit davantage d’un style architectural que d’un protocole. Il s’appuie sur HTTP pour transférer des données au format JSON ou XML. Les requêtes sont indépendantes les unes des autres et les réponses peuvent être mises en cache. Sa simplicité et sa capacité à passer à l’échelle expliquent pourquoi REST est souvent privilégié pour les services web et les applications mobiles.

En revanche, une sur-récupération ou une sous-récupération peut se produire : un client reçoit alors plus de données qu’il n’en a demandé ou, au contraire, n’obtient pas toutes les données nécessaires. De plus, comme REST utilise le protocole HTTP, il peut ne pas convenir à tous les types de données, applications et environnements. REST s’accompagne aussi de préoccupations de sécurité ; il peut présenter des vulnérabilités s’il n’est pas correctement maintenu.

SOAP

Simple Object Access Protocol, ou SOAP, est beaucoup plus strict et complexe que REST. Il utilise la norme de données XML et peut prendre en charge plusieurs protocoles de transfert de données, notamment HTTP et SMTP. Il prend en charge des fonctionnalités de sécurité avancées comme WS-Security. Il est principalement utilisé dans des cas qui privilégient la sécurité et le formalisme plutôt que la facilité d’utilisation par un large public, comme les services financiers ou les applications d’entreprise telles que Salesforce.

RPC

Le protocole d’appel de procédure à distance traite les données aux formats JSON et XML. Cependant, il diffère radicalement de REST et SOAP, car il appelle une méthode plutôt qu’une source de données. La réponse RPC indique qu’une action a été déclenchée ou a échoué. Comme l’appel à un serveur RPC modifie l’état d’un serveur, il est nécessaire de disposer d’un niveau de sécurité élevé entre les fournisseurs et les utilisateurs. Avec tout cela, les API RPC sont souvent privées. Cependant, RPC s’appuie sur le protocole HTTP/2 pour transférer les données, lequel n’est pas pris en charge nativement par la majorité des navigateurs ; vous pouvez donc avoir besoin d’équipements supplémentaires pour garantir son bon fonctionnement.

GraphQL

Bien que GraphQL soit appelé un protocole, c’est un langage de requête. Contrairement à REST, qui possède de nombreux endpoints, GraphQL n’en a généralement qu’un seul. GraphQL permet d’effectuer plusieurs requêtes dans une seule requête. Les utilisateurs peuvent préciser les données dont ils ont besoin, ce qui évite la sur-récupération ou la sous-récupération. En revanche, GraphQL présente certains défis en matière de mise en cache des données. Les fournisseurs doivent également fournir une documentation complète pour informer les utilisateurs des paramètres existants afin qu’ils puissent créer une requête.

Types d’API

Les API peuvent être classées de plusieurs façons : selon leur public cible ou selon leur architecture. Selon leur public, elles peuvent être publiques, partenaires ou privées ; selon leur architecture, elles peuvent être composites, unifiées, basées sur des microservices ou monolithiques.

API publiques

Également appelées ouvertes ou externes, les API publiques sont conçues pour un large public. Elles n’ont pas ou peu de restrictions ; même si elles nécessitent une authentification ou une inscription, le processus est simple, et les utilisateurs n’ont pas besoin de qualifications particulières pour utiliser cette API. Cependant, les API ouvertes peuvent tout de même nécessiter un paiement ou limiter les fonctionnalités des comptes gratuits. Par exemple, Google Maps API est une API publique.

API privées

Ce type d’API est également appelé API interne. Il cible un petit groupe d’utilisateurs, comme les personnes au sein d’une entreprise. Les utilisateurs ont besoin d’une autorisation pour accéder à ces API. Elles doivent être sécurisées, l’authentification peut donc prendre du temps et être complexe.

API partenaires

Les API partenairess se situent entre les API publiques et privées. Leur principal cas d’utilisation est le partage de données entre deux entreprises ou organisations ; ces API nécessitent donc toujours une authentification et sont sécurisées. Elles ciblent également un groupe d’utilisateurs, mais ce groupe est plus large que dans le cas des API privéess. Les informations partagées via ces API sont importantes et ne sont certainement pas destinées à un large public, mais elles ne sont pas aussi secrètes que les données partagées via des API privéess.

Par ailleurs, un quatrième type est parfois mentionné : OpenAPI Standard. Cependant, il ne s’agit pas d’un autre type d’API, mais d’un framework pour écrire des API publiques. Son nom d’origine était Swagger, et cet outil fournit des directives, ce qui rend l’écriture d’une API puis son utilisation plus simples et plus rapides. Toutefois, il est également inexact d’appeler les API publiques ” open APIs “, car toutes les API publiques ne suivent pas la norme. De plus, les API privéess peuvent utiliser la norme OpenAPI même sans être accessibles publiquement.

API monolithiques

Ces API sont créées comme une base de code unique qui donne accès à une source complexe. Leurs avantages incluent une fonctionnalité prévisible et la stabilité. En revanche, elles sont difficiles à faire évoluer ou à mettre à jour, car de nombreuses données sont connectées, et les changements peuvent provoquer des conséquences imprévisibles.

API de microservices

À l’inverse, dans une architecture de microservices, chaque service dispose de son API et remplit une fonction distincte. Il est facile de les mettre à jour ou de désactiver des parties qui ne sont plus nécessaires sans affecter tout le système. Cependant, les API de microservices produisent une énorme quantité de requêtes individuelles.

API composites

C’est là qu’interviennent les API composites. Elles peuvent cibler plusieurs endpoints dans un seul appel, choisir la combinaison d’appels la plus efficace, fournir les données nécessaires et éviter la duplication de code.

API unifiées

Les API unifiées sont proches des API composites : au lieu de solliciter plusieurs endpoints d’une même API, elles sollicitent plusieurs API. Le choix dépend de vos besoins.

Tests et surveillance des API

Comme tout autre logiciel, les API nécessitent des tests et une surveillance afin de garantir la stabilité, la sécurité et un niveau de performance élevé. Vous pouvez tester les API manuellement ou effectuer des tests automatisés. Il existe plusieurs types de tests d’API :

• tests fonctionnels – pour s’assurer qu’un serveur répond aux requêtes et que les réponses et les formats de données sont corrects ;
• tests de charge – aident à vérifier si une API fonctionne correctement en cas de pics de trafic ;
• tests de sécurité – nécessaires pour s’assurer qu’aucune faille n’est laissée aux fraudeurs ;
• tests de régression – lorsque des modifications sont apportées, les tests de régression sont nécessaires pour s’assurer qu’aucune conséquence inattendue et indésirable ne se produit ;
• tests de tolérance aux pannes – utiles pour vérifier comment un système répond à des requêtes potentiellement nuisibles, comme celles pouvant mener à une attaque DDoS.

Les développeurs testent les API aussi bien pendant le développement que lors du déploiement.

Pour conclure

Une API est un outil supplémentaire pour tirer le meilleur parti des technologies. Vous en utilisez souvent sans même vous en rendre compte, et de nombreuses fonctionnalités de vos sites web ou applications préférés reposent sur elles. DataImpulse vous aide à comprendre ces technologies grâce à des explications claires. Combiner plusieurs outils peut aussi améliorer vos résultats : par exemple, les tests d’API peuvent être plus efficaces avec des proxies. Nous avons également développé notre API, que vous pouvez utiliser pour revendre nos proxies et générer des revenus. Pour en savoir plus, écrivez-nous à [email protected] ou cliquez sur le bouton “Try now” dans l’angle supérieur droit de l’écran.