Une API Web côté client est une interface de programmation permettant d'étendre les fonctionnalités d'un navigateur Web ou d'un autre client HTTP. À l'origine, celles-ci se présentaient le plus souvent sous la forme d'extensions de navigateur natives, mais la plupart des API les plus récentes se basent sur des appels JavaScript standardisées.
La Fondation Mozilla a créé sa spécification d'API Web qui est conçue pour aider à remplacer les applications mobiles natives par des applications HTML5[1],[2].
Google a créé son architecture Native Client qui est conçue pour aider à remplacer les plug-ins natifs non sécurisés par des extensions et des applications natives sécurisées en bac à sable. Ils l'ont également rendu portable en utilisant un compilateurLLVMAOT modifié.
Côté serveur
Une API Web côté serveur est servie au moyen d'un serveur Web basé sur HTTP. Elle se compose d'un ou plusieurs points d'accès exposés publiquement répondant avec des données, généralement exprimé en JSON ou XML. Une API serveur (SAPI) n'est pas considérée comme une API Web côté serveur, sauf si elle est publiquement accessible par une application Web distante.
Les applications composites sont des applications Web qui combinent l'utilisation de plusieurs API Web côté serveur[3],[4],[5]. Les webhooks sont des API Web côté serveur qui prennent en entrée un identificateur de ressource uniforme (URI) conçu pour être utilisé comme un canal nommé distant ou un type de rappel tel que le serveur agit en tant que client pour déréférencer l'URI fourni et déclencher un événement sur un autre serveur qui gère cet événement fournissant ainsi un type d'IPC peer-to-peer.
Points d'accès
Les points d'accès sont des aspects importants de l'interaction avec les API Web côté serveur, car ils spécifient où se trouvent les ressources accessibles par des logiciels tiers. Généralement l'accès se fait via une URI sur laquelle sont postées les requêtes HTTP, et dont la réponse est donc attendue. Les API Web peuvent être publiques ou privées, cette dernière nécessitant un jeton d'accès.
Les terminaux doivent être statiques, sinon le bon fonctionnement des logiciels qui interagissent avec eux ne peut être garanti. Si l'emplacement d'une ressource change (et avec lui le point de terminaison), alors le logiciel précédemment écrit tombera en panne, car la ressource requise ne peut plus être trouvée au même endroit. Comme les fournisseurs d'API souhaitent toujours mettre à jour leurs API Web, beaucoup ont introduit un système de gestion des versions dans l'URI qui pointe vers un point de terminaison.
Ressources contre services
Les API Web Web 2.0 utilisent souvent des interactions machine telles que REST et SOAP. Les API Web RESTful utilisent des méthodes HTTP pour accéder aux ressources via des paramètres encodés en URL et utilisent JSON ou XML pour transmettre des données. En revanche, les protocoles SOAP sont normalisés par le W3C et imposent l'utilisation de XML comme format de charge utile, généralement via HTTP. De plus, les API Web basées sur SOAP utilisent la validation XML pour garantir l'intégrité structurelle des messages, en tirant parti des schémas XML fournis avec les documents WSDL. Un document WSDL définit avec précision les messages XML et les liaisons de transport d'un service Web.
Documentation
Les API Web serveur sont des interfaces permettant au monde extérieur d'interagir avec la logique métier. Pour de nombreuses entreprises, cette logique commerciale interne et la propriété intellectuelle qui y est associée sont ce qui les distingue des autres entreprises et potentiellement ce qui leur donne un avantage concurrentiel. Ils ne veulent pas que ces informations soient exposées.
Cependant, il existe désormais des répertoires d'API Web côté serveur documentées populaires[6]. Il existe également des standards qui permettent d'universaliser les APIs, permettant d'accéder aux APIs sans consulter au préalable une documentation. Le W3C a notamment publié les standards Solid dans ce sens.
Croissance et impact
Le nombre d'API Web disponibles n'a cessé d'augmenter au cours des dernières années, à mesure que les entreprises réalisent les opportunités de croissance associées à l'exécution d'une plate-forme ouverte, avec laquelle tout développeur peut interagir. ProgrammableWeb suit plus de 24 000 API Web disponibles en 2022, contre 105 en 2005[7].
Les API Web sont devenues omniprésentes. Il existe peu d'applications/services logiciels majeurs qui n'offrent pas une certaine forme d'API Web. L'une des formes les plus courantes d'interaction avec ces API Web consiste à intégrer des ressources externes, telles que des tweets, des commentaires Facebook, des vidéos YouTube, etc. En fait, il existe des entreprises très prospères, telles que Disqus, dont le service principal est de fournir des outils intégrables, tels qu'un système de commentaires riche en fonctionnalités[8]. Tout site Web du TOP 100 des sites Web classés par Alexa Internet utilise des API et/ou fournit ses propres API, ce qui est un indicateur très distinct de l'échelle prodigieuse et de l'impact des API Web dans leur ensemble[9].
À mesure que le nombre d'API Web disponibles augmentait, des outils open source ont été développés pour fournir une recherche et une découverte plus sophistiquées. APIs.json fournit une description lisible par machine d'une API et de ses opérations, et le projet connexe APIs.io propose une liste publique consultable d'API basée sur le format de métadonnées APIs.json[10],[11].
En entreprise
Entreprises privées
De nombreuses entreprises et organisations s'appuient fortement sur leur infrastructure d'API Web pour servir leurs principaux clients commerciaux. En 2014, Netflix a reçu environ 5 milliards de demandes d'API, la plupart au sein de son API privée[12].
Gouvernements
De nombreux gouvernements collectent beaucoup de données, et certains gouvernements ouvrent désormais l'accès à ces données. Les interfaces par lesquelles ces données sont généralement rendues accessibles sont les API Web. Les API Web permettent à tout développeur d'accéder de manière pratique à des données telles que "les données budgétaires, les travaux publics, la criminalité, les données juridiques et autres"[13].
Exemple
Un exemple d'API Web populaire est l'API Astronomy Picture of the Day exploitée par l'agence spatiale américaine NASA. Il s'agit d'une API côté serveur utilisée pour récupérer des photographies de l'espace ou d'autres images d'intérêt pour les astronomes, ainsi que des métadonnées sur les images.
Selon la documentation de l'API[14], l'API a un point de terminaison :
La documentation indique que ce point de terminaison accepte les requêtes GET. Il nécessite une information de l'utilisateur, une clé API, et accepte plusieurs autres informations facultatives. Ces éléments d'information sont appelés paramètres. Les paramètres de cette API sont écrits dans un format connu sous le nom de chaîne de requête, qui est séparé par un point d'interrogation ( ? ) du point de terminaison. Une esperluette ( & ) sépare les paramètres de la chaîne de requête les uns des autres. Ensemble, le point de terminaison et la chaîne de requête forment une URL qui détermine la manière dont l'API répondra. Cette URL est également connue sous le nom de requête ou d' appel d'API.
Dans l'exemple ci-dessous, deux paramètres sont transmis (ou transmis) à l'API via la chaîne de requête. Le premier est la clé API requise et le second est un paramètre facultatif - la date de la photographie demandée.
La visite de l'URL ci-dessus dans un navigateur Web lancera une requête GET, appelant l'API et affichant à l'utilisateur un résultat, appelé valeur de retour. Cette API renvoie JSON, un type de format de données destiné à être compris par les ordinateurs, mais qui est également assez facile à lire pour un humain. Dans ce cas, le JSON contient des informations sur une photographie d'une naine blanche :
{"date":"1996-12-03","explanation":"Like a butterfly,\r a white dwarf star begins its life\r by casting off a cocoon that enclosed its former self. In this\r analogy, however, the Sun would be\r a caterpillar\r and the ejected shell of gas would become the prettiest of all!\r The above cocoon, the planetary nebula\r designated NGC 2440, contains one of the hottest white dwarf stars known.\r The white dwarf can be seen as the bright dot near the photo's\r center. Our Sun will eventually become a \"white dwarf butterfly\",\r but not for another 5 billion years. The above false color image recently entered the public domain\r and was post-processed by F. Hamilton.\r","hdurl":"https://apod.nasa.gov/apod/image/9612/ngc2440_hst2_big.jpg","media_type":"image","service_version":"v1","title":"Cocoon of a New White Dwarf\r\nCredit:","url":"https://apod.nasa.gov/apod/image/9612/ngc2440_hst2.jpg"}
Le retour d'API ci-dessus a été reformaté afin que les noms des éléments de données JSON, appelés clés, apparaissent au début de chaque ligne. La dernière de ces clés, nommée url, indique une URL qui pointe vers une photographie :
En suivant l'URL ci-dessus, un utilisateur de navigateur Web verrait cette photo :
Bien que cette API puisse être appelée par un utilisateur final avec un navigateur Web (comme dans cet exemple), elle est destinée à être appelée automatiquement par un logiciel ou par des programmeurs informatiques lors de l'écriture d'un logiciel. Le JSON est destiné à être parsé par un programme informatique, qui en extrairait l'URL de la photographie et les autres métadonnées. La photo résultante peut être intégrée à un site Web, envoyée automatiquement par SMS ou utilisée à toute autre fin envisagée par un développeur de logiciel.
