Stories
API, l'ouverture des SI dans un monde de micro services
API : l'ouverture des SI dans un monde de micro services
Parce qu’elles interconnectent les systèmes dans un monde de plus en plus ouvert et décloisonné, les APIs, ces interfaces de programmation, forment aujourd’hui l’un des principaux moteurs des vastes projets de modernisation des SI des entreprises. Les APIs deviennent le mot à la mode quand on aborde la problématique d’agrégation et d’intégration de données et de services.
Les entreprises dans le monde s’adosseront aux APIs pour motoriser leur SI, et par extension leur modèle économique.
Rintio utilise cette nouvelle méthode et technologie pour l’intégration et le développement de ses applications et services.
Il a également validé de puissants et nombreux algorithmes et processus lui permettant de répondre aux exigences de son métier.La plupart de ces fonctions est déjà disponible comme service et est particulièrement stable.
Il suffit d’exposer ces fonctions au travers d’API pour qu’elles puissent interagir avec de nouveaux micro-services venant apporter la souplesse et l’évolutivité nécessaire à une transformation numérique réussie.
A la racine du développement de ces nouvelles applications conçues autour de micro-services se trouvent les API.
On peut regarder les API comme le contrat initial définissant l’information à fournir et la base syntaxique sur laquelle l’information est fournie. Dans le respect de ce contrat, un ou plusieurs nouveaux micro-services peuvent être créés, modifiés, supprimés sans impacter d’aucune manière les autres projets.
Au-delà de cette flexibilité qui permet, à peu de frais, la mise en place d’une démarche de type essai-erreur, le succès de ces micro-services repose sur les épaules de toutes petites équipes agiles.
Le principe du micro-service injecte de la flexibilité à un Système d’Information encore trop souvent monolithique.
Une méthode à laquelle devrait songer toute entreprise qui souhaite se réorganiser autour de sa transformation numérique.
Rintio l’a adoptée et en est aujourd’hui satisfait…
Quelle place pour les APIs dans une architecture de microservices
Les microservices représentent une refonte complète du design applicatif ainsi que du déploiement d’applications.
Une architecture de microservices peut impliquer de nombreux services, comme des VM, des conteneurs, des APIs, des services de load balancing, de monitoring ainsi que des outils d’automatisation, mais aussi d’autres éléments conçus pour renforcer la cohérence de l’application.
Toutefois, en dépit de ce principe, chaque élément fonctionnel peut exister indépendamment des autres.Les fournisseurs de services Cloud, comme AWS par exemple, se sont mis à développer une liste de services qui fonctionnent avec des projets de microservices, comme les conteneurs, la gestion d’événement ou encore la gestion d’APIs.
Bien que les microservices montent aujourd’hui en puissance, cette approche n’est pourtant pas adaptée à toutes les applications. Les développeurs doivent ainsi bien comprendre le principe des microservices, démarrer petit et employer l’architecture microservices lorsque cela fait sens.Les APIs sont devenues un moyen clé pour que les services Cloud s’échangent des informations et fonctionnent de concert pour au final créer une fonctionnalité ou un groupe de fonctions.
Avec les microservices, une application est conçue et implémentée comme un groupe de composants pouvant être dimensionnés, plutôt que comme une unique entité monolithique.
Une API peut par exemple permettre à des workloads dans plusieurs conteneurs de partager des données, de prendre en compte les entrées des utilisateurs et de gérer les sorties (pour être stockées ou pour être dirigées vers des services de reporting). Les APIs peuvent également permettre aux applets côté client de communiquer avec les applications côté serveurs, même lorsque ces composants applicatifs sont hébergés dans un Cloud public.
API : Comment automatiser la génération de code
Les APIs sont certes devenues un composante clé des architectures logicielles, les développeurs peinent encore à les façonner.
En cause : l’écart entre la publication de la documentation et celle des spécifications.
Brad Irby nous fait part d’un outil qui permet d’automatiser la génération de code.
Les APIs sont devenues très à la mode chez les développeurs. Mais en dépit de cette notoriété, ceux-ci doivent encore livrer bataille lorsqu’il s’agit de générer le code de l’API à cause de décalage entre la documentation et les demandes des chefs de produits.
Dans cet article, je vous explique comment Swagger peut aider à maintenir une cohérence entre la documentation et le code, tout le long du processus de création d’une application.
Nous sommes d’accord sur le fait que les APIs sont un outil formidable, mais leur création reste encore une tâche qui n’est pas aisée. Il est nécessaire de prendre en compte nombre de détails.
Mais il est également facile de perdre de vue certains de ces détails, lorsque l’on traduit l’idée de départ d’un chef de produit dans une série de documents détaillant les specs, puis enfin en ligne de code. Grâce à Swagger, synchroniser les docs avec le code est devenu plus simple.
Swagger est un outil qui permet à quiconque disposant d’un minimum de compétences techniques de définir une API, de générer la documentation et même de générer le code.
L’API est conçue au sien d’un éditeur en ligne via YALM, un langage XML très lisible.
Celui-ci définit les endpoints, puis le format des paramètres d’entrée et de sortie des données, le niveau de sécurité que vous souhaitez implémenter.
Et c’est prêt à être utilisé.
L’éditeur Swagger vous propose un exemple reposant sur l’API d’Instagram (Figure 1).
Dans l’éditeur, sélectionnez « File », puis « Open Example ». D’autres exemples sont également disponibles.
Figure 1 : L’API d’Instagram comme exemple
Parmi les données de l’illustration ci-dessus, 8 paths ont été définis. On clique sur le petit triangle pour dérouler les nœuds. Lorsque vous en ouvrez un (Figure 2), on constate que cela nécessite GET HTTP. Vous pouvez consulter la description et constater qu’il requiert 3 paramètres. Si cela marche, il retourne un array d’objets.
Figure 2 : Un path complet
De même, vous pouvez ouvrir la définition Media, et consulter les détails des propriétés de cet objet, comme les objets imbriqués (je ne montre qu’une partie de la définition dans la Figure 3
Partager :
