API est l’acronyme de « Application Programming Interface », qui se traduit en français par « Interface de Programmation d’Application ». Il s’agit d’un ensemble de règles, protocoles et outils qui permettent à différents logiciels de communiquer et d’interagir entre eux.
Plus précisément, une API définit les méthodes d’interaction entre différentes parties d’un système informatique, telles que des applications, des services web, des bases de données, des serveurs et des clients. Elle permet ainsi à ces parties de communiquer entre elles, de partager des données et des fonctionnalités, et d’utiliser les ressources des autres parties.
Par exemple, une API de paiement en ligne peut permettre à une boutique en ligne de communiquer avec un service de paiement tiers, en envoyant des informations sur les achats des clients et en recevant des réponses sur les transactions réussies ou non. De même, une API de géolocalisation peut permettre à une application mobile de localiser les utilisateurs et de leur fournir des informations sur leur position géographique.
On peut dire que l’API est un contrat qui définit les points d’accès à l’application, et cette définition contient en général:
- Le type de point d’accès. Ca peut être via le réseau, via des appels systèmes, via des fonctions dans une bibliothèque…
- Le protocole d’accès. Pour que les deux applications se comprennent, il est nécessaire qu’elles emploient le même langage: c’est le protocole. Par exemple, dans le cas de communication via le réseau, le protocole pourrait être HTTP (dans ce cas particulier, on parle de services web).
- La « localisation » du ou des point d’accès. Dans le cas du réseau, ça serait au minimum un hôte et un port, plus probablement un URI.
- Le format des données attendues en entrée. Il s’agit de définir quelles sont les données attendues par l’application, si elles sont obligatoires, facultatives, et sous quelle formalisation. Par exemple, si vous exposez un service web qui donne l’heure et la date, vous pouvez dire que vous attendez un fuseau horaire, ainsi qu’un format de date, exprimés sous la forme d’un code ISO pour le fuseau, et d’un code donné pour le format, passés en paramètre dans l’URL, et qu’il sont tous les deux facultatifs.
- Le format des données espérées en sortie. Il s’agit de la même chose, mais cette fois pour les données renvoyées par l’application, en réponse aux données fournies en entrées. Pour reprendre l’exemple précédent, on pourrait imaginer qu’il s’agit d’un fichier JSON qui contient un seul champ nommé « date », que sa valeur est la date et l’heure au moment de la requête, au fuseau horaire demandé (ou UTC, ou GMT, ou n’importe quel fuseau choisi arbitrairement mais défini par l’API, en l’absence de fuseau), et au format demandé (ou au format ISO, ou n’importe quel format choisi arbitrairement et défini par l’API, en l’absence de format).
- La gestion et le format des erreurs le cas échéant, pour que l’application appelante puisse réagir de façon appropriée