Maîtriser l’architecture des API : les fondamentaux des API

Byron McNaughtResponsable senior du marketing des solutions | F5

Les interfaces de programmation d’applications, ou API, ont le vent en poupe.

Bien que les API ne soient pas nouvelles, des phénomènes récents tels que l’accélération de la transformation numérique pendant la pandémie de COVID-19, le renforcement des intégrations logicielles et les efforts visant à migrer les applications existantes vers des plateformes cloud ont entraîné une prolifération des API continue, qui a des répercussions sur la gestion, la sécurité et même les choix architecturaux des organisations souhaitant réussir dans l’économie numérique moderne.

Les API peuvent, par essence, symboliser l’avènement des machines. Heureusement, les humains gardent encore le contrôle de leur conception, de leur gestion et de leur sécurité (du moins pour l’instant).

Fondamentalement, dans le « jargon des API » (si l’on peut dire), le consommateur envoie généralement des requêtes ou des demandes au producteur, par l’intermédiaire d’interfaces unifiées reposant sur différentes normes, différents schémas et différentes spécifications.

Par exemple, le National Weather Service (le « producteur ») fournit des données météorologiques quotidiennes. L’application météo de votre téléphone (le « consommateur ») appelle, ou plus précisément interroge, ce système via l’API REST WeatherKit, puis affiche les données dans son interface utilisateur. Bien qu’il s’agisse d’un exemple simple d’application populaire utilisée par des millions d’utilisateurs, il convient de noter que les communications de machine à machine représentent la majeure partie du trafic des expériences numériques modernes et qu’elles reposent sur les API.

Les API offrent de nombreux avantages technologiques qui se traduisent par une réelle valeur ajoutée pour l’entreprise :

En ce qui concerne la mise en œuvre des API, plusieurs aspects doivent être pris en compte, notamment la modélisation, la gestion des versions et les tests de contrat, qui permettent de découpler les dépendances et de garantir l’interopérabilité lors de la conception, du développement et de la maintenance.

Il n’existe pas de bonne ou de mauvaise façon de créer, de gérer et de sécuriser une API. En fait, lorsque les API ont commencé à se multiplier, il est devenu nécessaire de normaliser leur forme et leur structure afin de pouvoir les utiliser à grande échelle. C’est ainsi qu’est née l’initiative OpenAPI, qui a donné lieu à la spécification OpenAPI (OAS). Swagger était l’implémentation de référence initiale de la spécification OpenAPI, et la plupart des outils ont désormais adopté OpenAPI, qui n’a rien perdu de son panache (HA !)

En réalité, une API peut être conçue à l’aide de diverses normes, de différents schémas et de plusieurs spécifications. Par exemple, une présentation RESTful, un service gRPC et des connexions à un schéma GraphQL.

Mise en œuvre

Vue d’ensemble

Le transfert d’état représentationnel (REST) fournit un modèle architectural léger permettant de décrire des interfaces uniformes, le plus souvent en utilisant HTTP comme protocole de transport sous-jacent.

REST est de loin l’implémentation la plus répandue des architectures basées sur des API.

Rapport 2022 de Postman sur l’état des API

Avantages

• REST repose sur quelques règles très simples, avec une faible barrière à l’entrée et un modèle de domaine robuste, ce qui le rend relativement facile à mettre en œuvre.
• En tant que système en couches, REST masque la complexité des systèmes sous-jacents à son interface. Par exemple, le consommateur ignore qu’il interagit avec un système de base de données par l’intermédiaire d’un service web.
• REST prend en charge de manière flexible différents types de contenu (notamment JSON et YAML).

Quand l’utiliser

• Lorsque la spécification OpenAPI suffit à communiquer aux utilisateurs la forme et la structure des API.
• Lorsque la mise en cache doit être déterminée dynamiquement en fonction des en-têtes HTTP, car les requêtes du producteur vers le consommateur sont sans état par défaut.
• Lors de l’extension d’un modèle de ressource pour une API unique fournie par le producteur, ou de la mise à disposition de plusieurs API sur la même URL de base à l’aide de passerelles API.

GraphQL est un langage open source d’interrogation et de manipulation de données pour les API, ainsi qu’un environnement d’exécution permettant de traiter ces requêtes à partir de données existantes (développé par Facebook et désormais intégré à la Linux Foundation).

• Fournit un langage de requête permettant d’interroger plusieurs sources.
• Permet aux clients de demander précisément les champs nécessaires, y compris ceux provenant de plusieurs API, réduisant ainsi le temps de chargement initial.
• Le langage de schéma définit les types de chaque API ainsi que la manière dont les API se combinent, ce qui permet de proposer une version unique pour l’ensemble des API et simplifie ainsi la gestion des versions.

• Comme technologie complémentaire venant se superposer aux systèmes existants pour en masquer la complexité.
• Lorsqu’un consommateur d’API a besoin d’un accès, d’un filtrage et de fonctionnalités de requête uniformes sur un large éventail de services interconnectés.
• Avec les appareils mobiles, qui sont limités par la taille réduite de leur écran et la disponibilité du réseau.

gRPC est un framework moderne, open source et hautement performant d’appel de procédure à distance (RPC), placé sous l’égide de la Linux Foundation.

• Des performances élevées et une grande fiabilité grâce à l’utilisation de HTTP/2, de tampons de protocole légers, de charges utiles sérialisées et d’implémentations avec état.
• Prise en charge modulaire de l’équilibrage de charge, du traçage, des contrôles d’intégrité et de l’authentification.
• Grande interopérabilité des fonctions d’interface et des messages, avec une prise en charge complète des outils pour tous les langages.

• Pour le dernier kilomètre de l’informatique distribuée, afin de connecter les appareils, les applications mobiles et les navigateurs aux microservices backend, ainsi que pour les applications multiplateformes permettant des interactions entre mobiles, ordinateurs de bureau et objets connectés.
• Pour le trafic interconteneurs (« Est-Ouest »).
• Pour les interfaces externes (« Nord-Sud ») nécessitant la diffusion en continu, ainsi que pour les applications en temps réel telles que les messageries instantanées et les applications financières ou d’actualités.

Après cette introduction aux principes fondamentaux des API, nous verrons dans les prochains articles comment concevoir, gérer et sécuriser une architecture d’API, avant de mettre ces connaissances en pratique en migrant une application existante vers une plateforme cloud.

Vous souhaitez prendre une longueur d’avance ? Téléchargez l’e-book dès aujourd’hui :

Maîtriser l’architecture des API | eBook O'Reilly

À propos de l’auteur

Byron McNaughtResponsable senior du marketing des solutions | F5

Autres articles de Byron McNaught