Put the Web in Web API

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

• Citer deux raisons expliquant pourquoi les applications Web sont de plus en plus populaires
• Indiquer les utilisations courantes des API Web
• Comprendre l’économie des API et pourquoi elles ont enregistré une telle croissance

Les API sur réseau changent la donne

Les API disponibles ne sont pas seulement celles présentes sur un seul et même réseau local. Les développeurs et les intégrateurs non spécialistes peuvent aussi utiliser les API proposées par les systèmes et les périphériques distants. Il peut s’agir de connexions privées, comme les réseaux mis en place dans les entreprises disposant de plusieurs sites et centres de données, ou d’un réseau public comme Internet. Ce réseau étendu repose sur les points de terminaison d’API.

Voyez les points de terminaison comme des prises murales sur lesquelles les applications se branchent.

Le nombre et le type d’appareils pouvant être branchés sur des prises électriques ne sont limités que par l’imagination des inventeurs et la capacité du fournisseur d’électricité. De la même manière, le nombre d’applications pouvant tirer parti des données extraites par le point de terminaison d’une API n’est limité que par l’imagination des développeurs et la capacité de l’infrastructure du fournisseur d’API.

Voici un exemple concret : peu de temps après que Google a proposé une API pour Google Maps, des milliers de développeurs tiers se sont lancés dans la création d’applications uniques et innovantes qui utilisaient cette API, intégrant ainsi la fonctionnalité d’affichage des cartes de Google directement dans leurs applications. Pensez à Yelp, à Lyft, à Tesla et à toutes ces applications qui fournissent une carte et indiquent les droits d’auteur de Google dans un coin.

C’est pour cette raison que les API sont souvent considérées comme un moteur d’innovation, en particulier par les Trailblazers de l’intégration pour qui les nombreuses API à leur disposition sont autant de pièces détachées destinées à mettre en place de nouveaux résultats commerciaux et expériences client.

Économie des API

En fonction du volume d’appels ou d’autres méthodes de classification des niveaux de service, un fournisseur tel que Google peut facturer des frais au développeur d’applications pour utiliser son API. C’est de là que vient le concept d’économie des API.

Désormais, le développeur d’applications doit calculer tous les coûts d’utilisation de l’API par rapport au développement de ses fonctionnalités à partir de zéro. Comme c’est souvent le cas dans l’économie des API, le développeur peut également rechercher un fournisseur moins cher pour un service similaire. Google Maps, par exemple, compte plusieurs concurrents connus, dont Here.com.

La croissance de l’économie des API est due à la concurrence existant entre les fournisseurs de services qui répondent à la quête de productivité des développeurs et de données communes. Pour chaque type de fonctionnalité pouvant être appelé via l’API (comme le traitement des cartes de crédit, l’affichage des cartes, la navigation et la traduction), plusieurs fournisseurs d’API rivalisent afin d’attirer l’attention des développeurs d’applications et des intégrateurs non spécialistes. Au fur et à mesure que le nombre de fonctionnalités fournies sous la forme de services s’appuyant sur des API augmente, l’économie des API accélère le développement d’applications principalement composées d’API standard. Plus la solution finale est modulable, plus elle sera en mesure d’intégrer de nouvelles fonctionnalités d’autres API qui innovent en matière de capacités opérationnelles globales.

Croissance des API hier et aujourd’hui

Vous pensez peut-être que les API sur réseau sont la meilleure invention depuis le fil à couper le beurre. Vous vous demandez peut-être également, puisqu’elles sont si formidables, pourquoi l’industrie de la technologie ne les a pas développées plus tôt ? En fait, c’est ce qui s’est passé.

À l’époque d’Unix, il n’était pas rare que les programmeurs appellent à distance la logique métier à partir d’un autre ordinateur via un réseau à l’aide d’une technologie appelée RPC, ou appel de procédure distante.

Êtes-vous prêt à prendre une bonne gorgée d’acronymes ? Au fil du temps, les RPC ont laissé place à d’autres formes de demandes de données et de fonctionnalités distantes telles que le réseau DDE (Dynamic Data Exchange), l’architecture CORBA (Common Object Request Broker Architecture), l’échange de données informatisé (EDI), etc. Un jour, le protocole appelé XML-RPC (oui, RPC de nouveau !) est apparu et a ensuite évolué pour devenir ce que nous appelons maintenant des services Web, s’appuyant sur la norme XML et le protocole SOAP (Simple Object Access Protocol).

Chaque fois qu’une nouvelle technologie d’accès à distance aux données ou aux fonctionnalités a vu le jour, l’industrie a pensé que l’utopie avait finalement été réalisée. Ensuite, les API Web, aujourd’hui très populaires, sont arrivées. Ce sont celles qui, comme nous l’avons déjà expliqué, s’appuient sur les fonctionnalités déjà intégrées au protocole Web (HTTP) via l’utilisation de verbes spéciaux tels que GET, PUT et POST. Oui, il s’agit bien du même protocole Web que vous utilisez tous les jours pour consulter vos sites préférés.

L’avenir (possible) de l’intégration

Donc, si l’on en croit l’Histoire, la façon dont nous intégrons les systèmes sera amenée à évoluer. Il existe maintenant deux technologies de type API relativement nouvelles qui s’éloignent de l’approche Web actuellement privilégiée. L’une vient de Facebook et s’appelle GraphQL, et l’autre vient de Google et s’appelle gRPC.

Les deux ont leurs propres avantages par rapport aux API Web actuelles. Par exemple, GraphQL repose sur l’idée d’un graphique social et la manière dont différents éléments de données, tels que des amis, des photos, des lieux de travail, etc. forment un labyrinthe d’informations reliées entre elles. GraphQL permet de demander des informations à un graphique de données en une seule fois (par opposition aux allers-retours de demandes multiples nécessaires aux API traditionnelles pour obtenir le même résultat).

En revanche, la technologie gRPC offre d’autres avantages. Elle s’appuie sur HTTP/2 (HTTP version 2) qui peut diffuser des données de manière bidirectionnelle. En employant HTTP/2, gRPC peut transformer une API en une API streaming qui transmet ses données à l’application consommatrice dès qu’elles sont disponibles. Pour certaines applications en temps réel, comme un afficheur boursier, il s’agit d’un moyen beaucoup plus efficace d’obtenir des données, au lieu de forcer l’application à vérifier en permanence si de nouvelles données sont disponibles, comme le font les API traditionnelles.

Différentes technologies au service d’un même concept

Qu’il s’agisse du protocole Web, de GraphQL, de gRPC ou d’une approche fondée sur les API qui n’existe pas encore, le concept des API sur réseau consiste essentiellement à transformer une fonctionnalité métier en un service mis en réseau que d’autres applications peuvent traiter à distance en tant que partie externalisée de leur expérience client. Le développement du nombre de composants externalisables (l’économie des API) vous donne davantage d’occasions de dépasser la concurrence grâce à des innovations et des expériences qui seraient difficiles à élaborer entièrement en interne.

Il est également possible de tirer parti de ce phénomène en sens inverse. Posez-vous la question suivante : quelles compétences commerciales votre organisation devrait-elle proposer aux développeurs externes et à elle-même en tant que service mis en réseau sous la forme d’une API ? Il s’agit véritablement d’une problématique majeure, en particulier pour ceux d’entre vous qui cherchent à devenir des Trailblazers de l’intégration !