Intégration

Qu'est-ce qu'une API ?

Une interface de programmation d'application (API) est un ensemble d'outils, de définitions et de protocoles pour la création de logiciels applicatifs. Elle permet à votre produit ou service de communiquer avec d'autres produits et services sans connaître les détails de leur mise en œuvre. Les API peuvent simplifier le développement des applications et ainsi permettre aux développeurs de gagner du temps et aux entreprises d'économiser de l'argent. Lorsque vous concevez de nouveaux outils et produits, ou que vous assurez la gestion de ceux qui existent déjà, les API vous offrent plus de flexibilité, simplifient la conception, l'administration et l'utilisation et vous fournissent les moyens d'innover.

Imaginez, par exemple, un distributeur de livres. Ce distributeur pourrait fournir à ses librairies clientes une application qui leur permet de vérifier la disponibilité des livres auprès du fournisseur. Mais le développement de cette application risque de coûter cher et de durer longtemps, alors que l'application finale risque d'être limitée par la plateforme et de nécessiter une maintenance continue.

Le distributeur peut aussi fournir une API pour vérifier la disponibilité des stocks. Cette approche présente plusieurs avantages :

  • En accédant aux données via une API, les clients ont la possibilité de centraliser les informations sur leur inventaire.
  • Le distributeur peut modifier ses systèmes internes sans impacter l'expérience de ses clients, tant que le comportement de son API ne change pas.
  • Avec une API publique, les développeurs qui travaillent pour le distributeur, pour les librairies ou pour d'autres entreprises peuvent développer une application qui aide les clients à trouver les livres qu'ils souhaitent acheter. Ainsi, les distributeurs peuvent augmenter leurs ventes ou saisir de nouvelles opportunités commerciales.

En bref, avec les API, vous ouvrez l'accès à vos ressources, sans sacrifier le contrôle et la sécurité. Après, c'est vous qui choisissez les ressources que vous souhaitez partager, et avec qui. La connexion des API et la création des applications qui utilisent les données ou fonctionnalités exposées par les API peuvent se faire par l'intermédiaire d'une plateforme d'intégration distribuée qui connecte tout, y compris les systèmes existants et l'Internet des objets.

Il existe trois approches d'accès aux API.

API privées

L'API n'est utilisable qu'en interne. Cette approche permet de garder un contrôle total sur l'API.

API partenaires

L'API est partagée avec certains partenaires de l'entreprise. Cette approche peut générer de nouveaux flux de revenus sans compromettre la sécurité.

API publiques

L'API est accessible à tous. Cette approche autorise les tiers à développer des applications qui interagissent avec votre API et peut devenir source d'innovations.

L'innovation par les API

En rendant vos API accessibles à vos partenaires ainsi qu'aux tiers, vous pouvez :

  • générer de nouveaux canaux de revenus ou étendre ceux qui existent déjà ;
  • étendre la portée de votre marque ;
  • stimuler l'innovation Open Source ou améliorer l'efficacité grâce au développement et à la collaboration externes.

Intéressant, non ? Mais quel est le rôle des API dans tout ça ?

Reprenons notre exemple du distributeur de livres.

Imaginez qu'un partenaire de l'entreprise développe une application qui permet aux clients de localiser les livres qu'ils cherchent dans les rayons. En améliorant l'expérience client, cette application va attirer d'autres clients dans la librairie, elle-même cliente du distributeur, qui en fin de compte aura étendu son canal de revenus.

Une entreprise tierce peut aussi utiliser une API publique pour développer une application afin que les clients puissent acheter des livres directement auprès du distributeur, sans passer par la librairie. Dans ce cas, le distributeur aura ouvert un nouveau canal de revenus.

Une entreprise peut tirer parti du partage de ses API avec certains de ses partenaires ou avec le monde entier. Chaque partenariat vous permet d'étendre la notoriété de votre marque en parallèle de vos campagnes marketing. En rendant vos technologies publiques, avec une API publique par exemple, vous encouragez les développeurs à créer un écosystème d'applications autour de votre API. Plus les gens utilisent vos technologies, plus ils sont susceptibles de faire affaire avec vous.

Vous pouvez ainsi obtenir des résultats aussi inattendus qu'intéressants en ouvrant l'accès à vos technologies et ces résultats peuvent parfois bouleverser un secteur tout entier. Dans le cas de notre distributeur de livres, de nouvelles entreprises, comme un service de location de livres, peuvent provoquer un changement fondamental dans son fonctionnement. Les API publiques et partenaires vous permettent de profiter des innovations d'une communauté de développeurs plus large. Les idées novatrices peuvent germer n'importe où. Les entreprises doivent se tenir au courant des changements qui s'opèrent sur leur marché et se préparer à y faire face. C'est là que les API interviennent.

Les API, une histoire toute récente

Les API sont apparues à l'aube de l'informatique, avant même les ordinateurs personnels. À cette époque, elles étaient surtout utilisées en tant que bibliothèques pour les systèmes d'exploitation. Elles résidaient presque toutes en local sur les systèmes sur lesquels elles s'exécutaient, même si elles transféraient parfois des messages entre les mainframes. Presque 30 ans après, les API sont sorties de leurs environnements locaux. Au début des années 2000, elles sont devenues importantes pour l'intégration des données à distance.

API distantes

Les API distantes sont conçues pour interagir via un réseau de communication. Ici, « distant » signifie que les ressources manipulées par l'API ne se trouvent pas sur l'ordinateur qui formule la requête. Le réseau de communication le plus fréquemment utilisé étant Internet, la plupart des API sont conçues sur la base des normes Web. Toutes les API distantes ne sont pas des API Web, mais on peut supposer que toutes les API Web sont distantes.

Les API Web utilisent en général le protocole HTTP pour leurs messages de requête et fournissent une définition de la structure des messages de réponse. Les messages de réponse se présentent la plupart du temps sous la forme d'un fichier XML ou JSON. Ces deux formats sont les plus courants, car les données qu'ils contiennent sont faciles à manipuler pour les autres applications.


Améliorations apportées aux API

Les API n'ont cessé de se développer sur le Web aujourd'hui omniprésent, et plusieurs initiatives ont tenté de simplifier leur conception et d'augmenter leur utilité.

Un peu de SOAP et beaucoup de REST

Pour standardiser l'échange des informations entre les API toujours plus nombreuses, il a fallu développer un protocole : le « Simple Object Access Protocol », ou SOAP. Les API conçues d'après le protocole SOAP utilisent le format XML pour leurs messages et reçoivent des requêtes via HTTP ou SMTP. SOAP a pour objectif de simplifier l'échange des informations entre les applications qui s'exécutent dans des environnements différents ou qui ont été écrites dans des langages différents.

Le « Representational State Transfer », ou REST, est une autre tentative de normalisation. Les API Web qui respectent les contraintes de l'architecture REST sont appelées API RESTful. Ces deux éléments diffèrent sur un point fondamental : SOAP est un protocole, alors que REST est un style d'architecture. Cela signifie qu'il n'existe aucune norme officielle qui régit les API Web RESTful. Selon la définition proposée par Roy Fielding dans sa thèse « Architectural Styles and the Design of Network-based Software Architectures », les API sont RESTful tant qu'elles respectent les six contraintes de conception d'un système RESTful :

  • Une architecture client-serveur : une architecture REST est composée de clients, de serveurs et de ressources et elle traite les requêtes via le protocole HTTP.

  • Un serveur sans état : le contenu du client n'est jamais stocké sur le serveur entre les requêtes. Les informations sur l'état de la session sont, quant à elles, stockées sur le client.

  • Une mémoire cache : la mise en mémoire cache permet de se passer de certaines interactions entre le client et le serveur.

  • Un système à couches : des couches supplémentaires peuvent assurer la médiation dans les interactions entre le client et le serveur. Ces couches peuvent remplir des fonctions supplémentaires, telles que l'équilibrage de charge, le partage des caches ou la sécurité.

  • Code à la demande (facultatif) : un serveur peut étendre les fonctionnalités d'un client en lui transférant du code exécutable.

  • Interface uniforme : cette contrainte est capitale pour la conception des API RESTful et couvre quatre aspects différents :

    • Identification des ressources dans les requêtes : les ressources sont identifiées dans les requêtes et sont séparées des représentations retournées au client.

    • Manipulation des ressources par des représentations : les clients reçoivent des fichiers qui représentent les ressources. Ces représentations doivent contenir suffisamment d'informations pour être modifiées ou supprimées.

    • Messages autodescriptifs : tous les messages renvoyés au client contiennent assez d'informations pour décrire la manière dont celui-ci doit traiter les informations.

    • Hypermédia comme moteur du changement des états applicatifs : après avoir accédé à une ressource, le client REST doit être en mesure de découvrir toutes les autres actions disponibles par des hyperliens.

Ces contraintes peuvent sembler difficiles à appliquer, mais dans les faits, elles le sont moins qu'un protocole. C'est pour cette raison que les API RESTful sont en train de prendre le pas sur les API SOAP.

Architectures SOA et de microservices

Les deux approches architecturales qui utilisent le plus les API distantes sont l'architecture orientée services (SOA) et l'architecture de microservices. La SOA est l'approche la plus ancienne. Elle visait à l'origine à améliorer les applications monolithiques. Par définition, une application monolithique fait tout. Mais certaines fonctions peuvent être fournies par d'autres applications faiblement couplées via un modèle d'intégration, comme un ESB (Enterprise Service Bus).

Si l'architecture SOA est plus simple qu'une architecture monolithique sous bien des aspects, elle peut potentiellement provoquer des changements en cascade au sein de l'environnement si les interactions entre les différents composants ne sont pas parfaitement comprises. En complexifiant l'environnement, l'architecture SOA réintroduit une partie des problèmes qu'elle cherchait à résoudre.

Les architectures de microservices fonctionnent d'une manière très similaire, dans le sens où elles utilisent des services faiblement couplés. Par contre, elles poussent la déstructuration de l'architecture classique encore plus loin. Les services qui composent l'architecture de microservices utilisent une structure de messagerie commune, telle que les API RESTful. Ils se servent des API RESTful pour communiquer entre eux simplement, sans convertir leurs données ni recourir à des couches d'intégration supplémentaires. L'utilisation des API RESTful permet et favorise même l'accélération de la distribution des nouvelles fonctions et mises à jour. Chaque service est distinct. Vous pouvez remplacer, améliorer ou supprimer chacun d'entre eux sans affecter les autres services de l'architecture. Cette architecture légère vous aide à optimiser les ressources distribuées ou cloud et à faire évoluer chaque service de façon dynamique.

APIs and Red Hat

Red Hat gives you modular, lightweight, and comprehensive API solutions that are open source, open standards, and available on-premise or in the cloud.

Platform

Integrate your diverse IT assets with a distributed, flexible integration platform. Red Hat Fuse provides the infrastructure and tooling you need to integrate everything.

Platform

Manage your APIs for internal and external users with a platform that makes APIs easy to share, secure, distribute, control, and monetize.

Vous ne savez pas encore tout sur les API…