Worldlex Wiki 
Contrairement à une interface utilisateur , qui connecte un ordinateur à une personne, une interface de programmation d'application (API) connecte des ordinateurs ou des logiciels entre eux. Elle n'est pas destinée à être utilisée directement par un utilisateur final , mais uniquement par un programmeur qui l'intègre à un logiciel. Une API est souvent composée de différentes parties qui agissent comme des outils ou des services mis à la disposition du programmeur. Un programme ou un programmeur qui utilise l'une de ces parties est dit appeler cette portion de l'API. Les appels qui constituent l'API sont également appelés sous-programmes , méthodes, requêtes ou points d'accès . Une spécification d'API définit ces appels, c'est-à-dire qu'elle explique comment les utiliser ou les implémenter.
L'un des principaux objectifs des API est de masquer le fonctionnement interne d'un système, en n'exposant que les parties utiles au programmeur et en garantissant leur cohérence même en cas de modifications ultérieures du fonctionnement interne. Une API peut être conçue sur mesure pour une paire de systèmes spécifique, ou bien être une norme partagée permettant l'interopérabilité entre de nombreux systèmes.
Le terme API est souvent utilisé pour désigner les API web , qui permettent la communication entre ordinateurs connectés à Internet . Il existe également des API pour les langages de programmation , les bibliothèques logicielles , les systèmes d'exploitation et le matériel informatique . Les API ont vu le jour dans les années 1940, bien que le terme n'ait émergé que dans les années 1960 et 1970.
interface utilisateur , une API est généralement invisible pour les utilisateurs. Elle constitue la partie « sous le capot » d'un système logiciel, utilisée pour la communication entre machines.Une API bien conçue n'expose que les objets ou actions nécessaires au logiciel ou aux développeurs de logiciels. Elle masque les détails inutiles. Cette abstraction simplifie la programmation.
La création de logiciels à l'aide d'API a été comparée à l'utilisation de jeux de construction, tels que les briques Lego . Les services logiciels ou les bibliothèques logicielles sont analogues à ces briques ; ils peuvent être assemblés via leurs API, composant ainsi un nouveau produit logiciel. Le processus d'assemblage est appelé intégration .
Prenons l'exemple d'un capteur météorologique doté d'une API. Lorsqu'un message spécifique lui est transmis, le capteur détecte les conditions météorologiques actuelles et renvoie un bulletin météo. Le message qui active le capteur correspond à un appel d'API, et le bulletin météo à une réponse de l'API . Une application de prévision météorologique peut s'intégrer à plusieurs API de capteurs météorologiques et collecter des données météorologiques sur une zone géographique donnée.
Une API est souvent comparée à un contrat . Elle représente un accord entre deux parties : un fournisseur de services qui propose l’API et les développeurs de logiciels qui l’utilisent. Si l’API reste stable, ou si elle n’évolue que de manière prévisible, la confiance des développeurs envers l’API augmentera. Cela peut accroître leur utilisation de l’API.
Historique du terme
Le terme API désignait initialement une interface uniquement pour les programmes destinés à l'utilisateur final, appelés programmes d'application . Cette origine se reflète encore dans le nom « interface de programmation d'application ». Aujourd'hui, le terme est plus large et inclut également les logiciels utilitaires et même les interfaces matérielles .
L'idée d'API est bien antérieure au terme lui-même. Dans les années 1940, les informaticiens britanniques Maurice Wilkes et David Wheeler travaillaient sur une bibliothèque logicielle modulaire pour EDSAC , un des premiers ordinateurs. Les sous-programmes de cette bibliothèque étaient stockés sur des bandes perforées, rangées dans un classeur . Ce classeur contenait également ce que Wilkes et Wheeler appelaient un « catalogue de bibliothèque », un ensemble de notes décrivant chaque sous-programme et la manière de l'intégrer à un programme. Aujourd'hui, un tel catalogue serait appelé API (ou spécification d'API, ou documentation d'API), car il indique au programmeur comment utiliser (ou « appeler ») chaque sous-programme dont il a besoin.
L'ouvrage de Wilkes et Wheeler, * The Preparation of Programs for an Electronic Digital Computer*, contient la première spécification API publiée. Joshua Bloch considère que Wilkes et Wheeler ont « inventé de manière latente » l'API, car il s'agit davantage d'un concept découvert que d'un concept inventé.
Le terme « interface de programmation d'application » (sans suffixe « -ing ») apparaît pour la première fois dans un article intitulé « Data structures and techniques for remote computer graphics » , présenté lors d'une conférence de l'AFIPS en 1968. Les auteurs de cet article utilisent ce terme pour décrire l'interaction d'une application — un programme graphique en l'occurrence — avec le reste du système informatique. Une interface d'application cohérente (constituée d'appels de sous-programmes Fortran ) visait à affranchir le programmeur des spécificités du périphérique d'affichage graphique et à garantir l'indépendance matérielle en cas de remplacement de l'ordinateur ou de l'écran.
Le terme a été introduit dans le domaine des bases de données par C.J. Date dans un article de 1974 intitulé « The Relational and Network Approaches: Comparison of the Application Programming Interface » . Une API est devenue partie intégrante du cadre ANSI/SPARC pour les systèmes de gestion de bases de données . Ce cadre traitait l'interface de programmation d'applications séparément des autres interfaces, telles que l'interface de requête. Dans les années 1970, les spécialistes des bases de données ont constaté que ces différentes interfaces pouvaient être combinées ; une interface d'application suffisamment riche pouvait également prendre en charge les autres interfaces
Cette observation a conduit à la création d'API prenant en charge tous les types de programmation, et non seulement la programmation d'applications. En 1990, l'API était simplement définie comme « un ensemble de services mis à la disposition d'un programmeur pour effectuer certaines tâches » par le technologue Carl Malamud .
L'idée d'API a connu un nouvel essor avec l'avènement des appels de procédure distante et des API Web . Dans les années 1970 et 1980, la généralisation des réseaux informatiques a incité les programmeurs à vouloir appeler des bibliothèques non seulement sur leur ordinateur local, mais aussi sur des ordinateurs distants. Ces appels de procédure distante étaient particulièrement bien pris en charge par le langage Java . Dans les années 1990, avec la diffusion d' Internet , des normes telles que CORBA , COM et DCOM se sont imposées comme la méthode la plus courante d'exposition des services API.
La thèse de doctorat de Roy Fielding , intitulée « Styles architecturaux et conception d'architectures logicielles réseau », soutenue à l'UC Irvine en 2000, a présenté l' architecture REST ( Representational State Transfer ) et décrit le concept d'« interface de programmation d'applications réseau », qu'il opposait aux API traditionnelles basées sur des bibliothèques. Les API web XML et JSON ont connu une large adoption commerciale à partir de 2000 et se sont poursuivies jusqu'en 2021. L'API web est aujourd'hui le sens le plus courant du terme API.
Le Web sémantique, proposé par Tim Berners-Lee en 2001, incluait les « API sémantiques » qui redéfinissaient l'API comme une interface de données ouverte et distribuée plutôt que comme une interface de comportement logiciel. Les interfaces et agents propriétaires se sont davantage répandus que les interfaces et agents ouverts, mais l'idée de l'API comme interface de données s'est imposée. Les API Web étant largement utilisées pour l'échange de données de toutes sortes en ligne, le terme API est devenu un terme générique désignant une grande partie des communications sur Internet. Dans ce contexte, le terme API recoupe en signification celui de protocole de communication .
Types
Bibliothèques et frameworks
L'interface d'une bibliothèque logicielle est un type d'API. L'API décrit et prescrit le « comportement attendu » (une spécification), tandis que la bibliothèque est une « implémentation concrète » de cet ensemble de règles.
Une seule API peut avoir plusieurs implémentations (ou aucune, étant abstraite) sous la forme de différentes bibliothèques partageant la même interface de programmation.
La séparation de l'API et de son implémentation permet aux programmes écrits dans un langage d'utiliser une bibliothèque écrite dans un autre. Par exemple, comme Scala et Java sont compilés en bytecode compatible , les développeurs Scala peuvent tirer parti de n'importe quelle API Java.
L’utilisation des API peut varier selon le type de langage de programmation utilisé. Une API pour un langage procédural comme Lua pourrait consister principalement en des routines de base pour exécuter du code, manipuler des données ou gérer les erreurs, tandis qu’une API pour un langage orienté objet , comme Java, fournirait une spécification des classes et de leurs méthodes . La loi de Hyrum stipule que « lorsqu’un nombre suffisant d’utilisateurs d’une API ont accès à des fonctionnalités spécifiques, les engagements contractuels importent peu : tous les comportements observables du système seront utilisés par au moins une personne » Par ailleurs, plusieurs études montrent que la plupart des applications utilisant une API n’en exploitent généralement qu’une petite partie
Les liaisons de langage sont également des API. En faisant correspondre les fonctionnalités d'un langage à une interface implémentée dans un autre langage, une liaison de langage permet d'utiliser une bibliothèque ou un service écrit dans un langage lors du développement dans un autre langage. Des outils tels que SWIG et F2PY, un générateur d'interfaces Fortran vers Python , facilitent la création de telles interfaces.
Une API peut également être liée à un framework logiciel : un framework peut être basé sur plusieurs bibliothèques implémentant plusieurs API, mais contrairement à l’utilisation normale d’une API, l’accès au comportement intégré au framework se fait en étendant son contenu avec de nouvelles classes intégrées au framework lui-même.
De plus, le flux de contrôle global du programme peut échapper au contrôle de l'appelant et être entre les mains du framework par inversion de contrôle ou un mécanisme similaire.
Systèmes d'exploitation
Une API peut spécifier l'interface entre une application et le système d'exploitation . POSIX , par exemple, spécifie un ensemble d'API communes qui visent à permettre à une application écrite pour un système d'exploitation conforme à POSIX d'être compilée pour un autre système d'exploitation conforme à POSIX.
Linux et Berkeley Software Distribution sont des exemples de systèmes d'exploitation qui implémentent les API POSIX.
Microsoft a démontré un fort engagement envers une API rétrocompatible, notamment au sein de sa bibliothèque Windows API (Win32), permettant ainsi aux anciennes applications de s'exécuter sur les versions plus récentes de Windows grâce à un paramètre spécifique appelé « Mode de compatibilité » . L'avantage réel dont bénéficient les développeurs Microsoft grâce à l'accès aux API internes de ses systèmes d'exploitation reste flou. En 1987, Richard A. Shaffer, de la revue Technologic Computer Letter, comparait la situation à un match de baseball où « Microsoft contrôle tout le terrain et toutes les battes » De grands éditeurs comme Lotus Development et Ashton-Tate auraient reçu des informations sur MS-DOS 5.0 auxquelles les développeurs de logiciels plus modestes n'avaient pas accès . Cependant, Ed Esber, d'Ashton-Tate, déclarait dans une interview de 1987 que Bill Gates lui avait confié que ses développeurs devaient parfois réécrire des logiciels basés sur d'anciennes API. Gates a fait remarquer dans l'interview que les applications Apple Macintosh de Microsoft étaient plus réussies que celles pour MS-DOS, car son entreprise n'avait pas à consacrer également des ressources à Mac OS .
Une API diffère d'une interface binaire d'application (ABI) en ce qu'une API est basée sur le code source tandis qu'une ABI est basée sur le binaire . Par exemple, POSIX fournit des API tandis que la base de normes Linux fournit une ABI.
API distantes
Les API distantes permettent aux développeurs de manipuler des ressources distantes via des protocoles , des normes de communication spécifiques qui permettent à différentes technologies de fonctionner ensemble, indépendamment du langage ou de la plateforme. Par exemple, l'API Java Database Connectivity permet aux développeurs d'interroger de nombreux types de bases de données avec le même ensemble de fonctions, tandis que l' API Java Remote Method Invocation utilise le protocole Java Remote Method pour permettre l'appel de fonctions qui s'exécutent à distance, mais apparaissent comme locales pour le développeur.
Par conséquent, les API distantes sont utiles pour maintenir l'abstraction objet dans la programmation orientée objet ; un appel de méthode , exécuté localement sur un objet proxy , invoque la méthode correspondante sur l'objet distant, en utilisant le protocole de communication à distance, et acquiert le résultat à utiliser localement comme valeur de retour.
Une modification de l'objet proxy entraînera également une modification correspondante de l'objet distant.
API Web
Dans le contexte du développement web , une API est généralement définie comme un ensemble de spécifications, telles que les messages de requête HTTP , ainsi que la structure des messages de réponse, généralement au format XML ou JSON . Par exemple, une API de transporteur peut être intégrée à un site e-commerce pour faciliter la commande de services de livraison et inclure automatiquement les tarifs en vigueur, sans que le développeur n'ait à saisir la grille tarifaire du transporteur dans une base de données web. Si l'expression « API web » a longtemps été synonyme de « service web » , la tendance récente ( Web 2.0 ) s'éloigne des services web basés sur SOAP et de l'architecture orientée services (SOA) pour privilégier les ressources web REST et l'architecture orientée ressources (ROA). Cette tendance est en partie liée au mouvement du Web sémantique et à son recours au RDF, un concept visant à promouvoir les technologies d'ingénierie d'ontologies web . Les API Web permettent de combiner plusieurs API pour créer de nouvelles applications appelées mashups . Dans le domaine des médias sociaux, les API Web ont permis aux communautés en ligne de faciliter le partage de contenu et de données entre communautés et applications. Ainsi, le contenu créé à un endroit peut être publié et mis à jour dynamiquement sur plusieurs plateformes Web. Par exemple, l'API REST de Twitter permet aux développeurs d'accéder aux données principales de Twitter, et l'API de recherche fournit des méthodes permettant d'interagir avec les données de recherche et de tendances de Twitter.
Conception
La conception d'une API a un impact significatif sur son utilisation. Le principe d' encapsulation décrit le rôle des interfaces de programmation comme permettant une programmation modulaire en masquant les détails d'implémentation des modules, de sorte que les utilisateurs n'aient pas à comprendre leur fonctionnement interne. Ainsi, la conception d'une API vise à fournir uniquement les outils dont un utilisateur a besoin. La conception des interfaces de programmation représente une partie importante de l'architecture logicielle , c'est-à-dire l'organisation d'un logiciel complexe.
Politiques de publication
Les API sont l'un des moyens les plus courants d'intégration des entreprises technologiques. Celles qui fournissent et utilisent des API sont considérées comme faisant partie d'un écosystème commercial.
Les principales politiques de publication d'une API sont :
- Privé : L'API est réservée à un usage interne à l'entreprise.
- Partenaire : Seuls certains partenaires commerciaux peuvent utiliser l’API. Par exemple, les entreprises de VTC comme Uber et Lyft autorisent les développeurs tiers agréés à commander directement des courses depuis leurs applications. Cela leur permet d’exercer un contrôle qualité en sélectionnant les applications ayant accès à l’API et leur procure une source de revenus supplémentaire.
- Public : L’API est accessible au public. Par exemple, Microsoft rend publique l’ API Windows et Apple publie son API Cocoa , permettant ainsi le développement de logiciels pour leurs plateformes . Toutes les API publiques ne sont pas accessibles à tous. Par exemple, les fournisseurs d’accès Internet comme Cloudflare ou Voxility utilisent des API REST pour permettre à leurs clients et revendeurs d’accéder aux informations relatives à leur infrastructure, aux statistiques DDoS, aux performances du réseau ou aux outils de contrôle du tableau de bord. L’accès à ces API est accordé soit par des « jetons d’API », soit par validation du statut client.
Implications des API publiques
Un facteur important lors de la mise en ligne d'une API est la « stabilité de son interface ». Les modifications apportées à l'API, par exemple l'ajout de nouveaux paramètres à un appel de fonction, pourraient rompre la compatibilité avec les clients qui dépendent de cette API.
Lorsque certaines parties d'une API publique sont susceptibles d'évoluer et donc instables, ces parties doivent être explicitement documentées comme « instables ». Par exemple, dans la bibliothèque Google Guava , les parties considérées comme instables, et susceptibles d'évoluer prochainement, sont marquées par l' annotation Java `@Beta @Unstable` .
Une API publique peut parfois déclarer certaines de ses parties comme obsolètes ou supprimées. Cela signifie généralement qu'une partie de l'API devrait être considérée comme susceptible d'être supprimée ou modifiée de manière incompatible avec les versions précédentes. Par conséquent, ces modifications permettent aux développeurs de se détacher progressivement des parties de l'API qui seront supprimées ou non prises en charge à l'avenir.
Le code client peut contenir des utilisations innovantes ou opportunistes non prévues par les concepteurs de l'API. Autrement dit, pour une bibliothèque disposant d'une large base d'utilisateurs, lorsqu'un élément est intégré à l'API publique, il peut être utilisé de diverses manières. Le 19 février 2020, Akamai a publié son rapport annuel « État d'Internet », mettant en lumière la tendance croissante des cybercriminels à cibler les plateformes d'API publiques des services financiers à travers le monde. De décembre 2017 à novembre 2019, Akamai a recensé 85,42 milliards d'attaques par violation d'identifiants. Environ 20 % d'entre elles, soit 16,55 milliards, visaient des noms d'hôtes définis comme points de terminaison d'API. Parmi celles-ci, 473,5 millions ciblaient des organisations du secteur des services financiers.
Documentation API
La documentation de l'API décrit les services offerts par une API et comment les utiliser, dans le but de couvrir tout ce qu'un client pourrait avoir besoin de savoir à des fins pratiques.
La documentation est essentielle au développement et à la maintenance des applications utilisant l'API. La documentation de l'API se trouve traditionnellement dans des fichiers de documentation, mais elle peut également être consultée sur les réseaux sociaux tels que les blogs, les forums et les sites de questions-réponses.
Les fichiers de documentation traditionnels sont souvent présentés via un système de documentation, tel que Javadoc ou Pydoc, qui possède une apparence et une structure cohérentes. Cependant, les types de contenu inclus dans la documentation diffèrent d'une API à l'autre.
Par souci de clarté, la documentation d'une API peut inclure une description des classes et des méthodes, ainsi que des exemples d'utilisation, des extraits de code, des justifications de conception, des analyses de performance et des contrats. En revanche, les détails d'implémentation des services API eux-mêmes sont généralement omis. Cette documentation peut prendre différentes formes : documents d'instruction, tutoriels, ouvrages de référence, etc. Elle comprend également divers types d'informations, comme des guides et des descriptions de fonctionnalités.
Les restrictions et limitations d'utilisation de l'API sont également décrites dans la documentation. Par exemple, la documentation d'une fonction API peut préciser que ses paramètres ne peuvent pas être nuls et que la fonction elle-même n'est pas thread-safe . Du fait de l'exhaustivité de la documentation API, il est difficile pour les rédacteurs de la maintenir à jour et pour les utilisateurs de la lire attentivement, ce qui peut engendrer des bogues.
La documentation de l'API peut être enrichie d'informations de métadonnées telles que des annotations Java . Ces métadonnées peuvent être utilisées par le compilateur, les outils et l' environnement d'exécution pour implémenter des comportements ou une gestion personnalisés.
Il est possible de générer la documentation d'une API à partir des données. En observant de nombreux programmes utilisant une API donnée, on peut déduire les usages typiques, ainsi que les contrats et directives requis. Des modèles peuvent ensuite être utilisés pour générer du langage naturel à partir des données extraites.
Litige relatif à la protection des droits d'auteur des API
Accepter la revendication d'Oracle reviendrait à permettre à quiconque de déposer des droits d'auteur sur une version de code permettant d'exécuter un système de commandes et, de ce fait, d'empêcher tous les autres d'écrire des versions différentes de ce code pour exécuter tout ou partie des mêmes commandes.
La décision d'Alsup a été annulée en 2014 en appel devant la Cour d'appel du circuit fédéral , bien que la question de savoir si une telle utilisation des API constitue une utilisation équitable soit restée sans réponse.
En 2016, à l'issue d'un procès de deux semaines, un jury a conclu que la réimplémentation de l'API Java par Google relevait de l'usage loyal , mais Oracle a annoncé son intention de faire appel. Oracle a obtenu gain de cause en appel, la Cour d'appel du circuit fédéral ayant statué que l'utilisation des API par Google ne constituait pas un usage loyal. En 2019, Google a saisi la Cour suprême des États-Unis concernant les décisions relatives au droit d'auteur et à l'usage loyal, et la Cour suprême a accepté d'examiner l'affaire. En raison de la pandémie de COVID-19 , les audiences orales ont été reportées à octobre 2020.
L'affaire a été tranchée par la Cour suprême en faveur de Google.