Livre blanc. Plate-forme de distribution d'api nouvelle génération Comment utiliser un serveur d'api pour gérer, distribuer et protéger les API

Transcription

1 Livre blanc Plate-forme de distribution d'api nouvelle génération Comment utiliser un serveur d'api pour gérer, distribuer et protéger les API.

2 Table des matières Table des matières... 2 Introduction... 3 Nouveaux modèles d'applications... 4 Changements liés à la conception des applications... 4 Changements liés à l'utilisation des applications... 5 Phénomène du «Bring-Your-Own»... 5 Architecture applicative traditionnelle... 7 Architecture applicative de nouvelle génération...ǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥǥ 8 Niveau services d'infrastructure (IS)... 9 Niveau distribution de services d'entreprise (BSD) Fonctions clés du serveur d'api Transformation des API Contrôle et gouvernance des API Sécurité des API Surveillance et reporting des API Cycle de vie de développement des API Administration des API Résumé Ǧ ǤǤǤǤ Page 2

3 Introduction Lors du lancement de l'iphone avec son App Store en 2007, Apple a engagé une transformation de l'utilisation, de la conception et de la distribution des applications. Avant l'apparition de l'iphone, les applications s'apparentaient à des blocs monolithiques dotés de milliers de fonctions. L'utilisateur lambda n'exploitait que 15 % des fonctions disponibles tout en payant l'intégralité du produit. On ne recensait qu'une minorité de fournisseurs, tandis que les mises à jour des produits demandaient au moins 12 mois. L'interaction utilisateur demeurait une expérience singulière au cœur d'une interface Web. Grâce aux API, les services d'entreprise sur le Web et les canaux mobiles et partenaires génèrent de nouveaux revenus, permettant d'établir une interaction riche avec les clients potentiels et de collaborer plus efficacement avec les partenaires. Les apps pour iphone ont changé la donne. Ces petites applications se composaient d'ensembles de fonctions simples. Elles étaient peu coûteuses et le choix très vaste. Les utilisateurs essayaient constamment de nouvelles applications et n'hésitaient pas à changer pour de nouvelles applications en offrant plus. Des services populaires comme Google Maps sont venus enrichir ces applications. Une application pouvait être créée en un clin d'œil, en assemblant des services et fonctionnalités existants de façon créative. Les améliorations semblaient ne devoir connaître aucune limite. Prenant acte de cette évolution, les entreprises ont commencé à exploiter ce nouveau modèle d'application pour développer leur activité et optimiser leur mode de travail. Il existe maintenant des applications particulières pour chaque événement et chaque enseigne, à l'instar des Jeux Olympiques et de Starbucks. Les applications mobiles sont désormais intégrées aux usages du web, ce qui permet à l'utilisateur de bénéficier d'un environnement intégré et homogène. Vous pouvez dorénavant saisir vos frais et prendre des photos des justificatifs avec votre téléphone mobile, puis finaliser et transmettre le décompte de frais via l'application Web. La distribution des applications sur différentes plates-formes intervient rapidement grâce à des API (Application Programming Interface). Les API permettent de distribuer des services applicatifs utilisables par d'autres applications. Le concept d'api n'a rien de nouveau. La nouveauté réside dans les modèles de conception centrés sur Internet, qui rendent les nouvelles API légères, portables et plus simples d'utilisation que les API traditionnelles (services Web, JMS et transfert de fichiers sécurisé notamment). En s'appuyant sur les conceptions des nouvelles API, les entreprises peuvent désormais proposer plus rapidement de nouveaux services à leurs clients, partenaires, employés et fournisseurs, de façon simultanée, via plusieurs canaux mobiles et Web. Pour les entreprises, les API constituent un facteur de compétitivité dans le monde de la mobilité et du cloud computing. Dans ce contexte, elles cherchent à gagner en efficacité et en évolutivité en distribuant des API et en développant l'usage de leur infrastructure d'applications existante. Ce livre blanc étudie la façon dont l'architecture applicative évolue pour. Page 3

4 permettre la distribution plus rapide de services d'entreprise via des API. Il traite également du rôle du serveur d'api dans cette architecture applicative moderne, qui associe mobilité et cloud. Ce livre blanc s'adresse aux architectes d'applications d'entreprise ou personnes occupant des responsabilités similaires. Il a pour objectif d'aider le lecteur à comprendre la transformation du paysage technologique des API et des applications, dans le contexte du développement d'une stratégie et d'une architecture de référence pour la distribution d'api, la mobilité et le cloud computing. Pour de plus amples informations sur le produit Vordel API Server et les autres solutions Axway, rendez-vous sur / Vous y trouverez toutes les informations utiles sur les produits, les études de cas et les bonnes pratiques. Nouveaux modèles d'applications La façon dont nous utilisons les applications évolue, appelant un changement du mode de diffusion des services par les entreprises. Pour commencer, regardons de plus près les modifications liées aux modèles d'utilisation des applications. Changements liés à la conception des applications L'utilisation des applications fait désormais intervenir plusieurs platesformes dotées d'api mobiles et Web. Stimulée par les applications mobiles et en mode cloud, la conception d'applications se caractérise maintenant par : Le niveau de granularité des fonctions ; sa spécialisation ; sa légèreté et son optimisation vis à vis des plates-formes cibles. Figure 1 : Les applications sont spécialisées et adaptées aux différentes plates-formes Les changements induits par l'arrivée de l'app Store d'apple ont marqué le passage d'un petit nombre d'applications d'une grande richesse fonctionnelle à Page 4

5 une gamme diversifiée de nombreuses applications spécialisées. Initialement imposé par la nature limitée des ressources de la plate-forme mobile, ce nouveau modèle de conception d'applications s'est finalement avéré le plus populaire. Simples d'utilisation, les nouvelles applications ne nécessitent quasiment aucune formation. Leur simplicité est synonyme de robustesse, et leur légèreté est synonyme de portabilité. Les exemples dans ce domaine ne manquent pas, qu'il s'agisse de l'app pour iphone Starbucks, d'instagram ou de Google Apps. Changements liés à l'utilisation des applications À l'heure actuelle, plus de 40 % des utilisateurs de smartphones possèdent également une tablette et la plupart des gens ont accès à un ordinateur. Les appareils domestiques, les téléviseurs et les automobiles deviennent des platesformes applicatives avec lesquelles nous pouvons interagir. Une même application étant désormais accessible via différentes plates-formes techniques, les utilisateurs veulent pouvoir changer de terminal facilement et profiter des avantages de chaque plate-forme. Ainsi, le nouveau modèle d'utilisation se présente comme suit : Points d'accès multiples : smartphone, tablette, téléviseur, etc. Utilisation sur multi plates-formes : utilisation à la fois différente et cohérente sur les diverses plates-formes. Types d'applications mixtes : Web, mobile, natif, intégré, composite. Phénomène du «Bring-Your-Own» Adoptez le nouveau modèle Open API and Community Developer en optant pour une plate-forme de distribution d'api robuste. Le phénomène désormais incontournable du «Bring-Your-Own» (le fait d'utiliser des ressources personnelles dans le cadre professionnel) a également une incidence sur la mise à disposition des applications. Il implique une grande variété de terminaux, services, applications et standards, que l'infrastructure informatique doit prendre en charge et dont elle doit assurer la sécurité. Bring-Your-Own-Device Il y a quelques années, les salariés avaient accès à du matériel informatique de pointe fournit par leur employeur, qu'il s'agisse d'ordinateurs portables ou de smartphones BlackBerry. À présent, l'électronique grand public est si évoluée et adaptée au monde professionnel que les salariés utilisent également leurs appareils électroniques dernier cri dans le cadre de leur activité professionnelle. Depuis que les salariés utilisent leurs équipements personnels, le service informatique ne peut plus se fier aux spécifications des machines et configurations logicielles figées. Les applications doivent désormais être adaptées à toutes les plates-formes courantes, sans aucune concession vis-à-vis de la sécurité et de la fiabilité. Page 5

6 Bring-Your-Own-Identity Les consommateurs préfèrent désormais choisir l'identité qu'ils utilisent pour accéder aux applications. Les fournisseurs d'identité dans le cloud, comme Google et Facebook, permettent aux consommateurs de se connecter à plusieurs applications à l'aide de leur mode d'identification favori. Pour faire des adeptes, les applications doivent prendre en charge le mode d'authentification et d'autorisation Bring-Your-Own-Identity. À l'heure où des standards du type OAuth poursuivent leur évolution en vue d'une utilisation en entreprise, on peut penser que les employés se connecteront un jour aux applications des partenaires à l'aide des données d'identification fournis par leur propre société. Bring-Your-Own-Application S'il est vrai que les applications gagnent en convivialité, le développement tend lui aussi à se simplifier. Des technologies telles que REST et JSON ont nettement réduit les compétences nécessaires pour créer des applications, tandis que des outils de développement de plate-forme tels qu'ios, Android et Dojo ont contribué à simplifier le processus de développement. Cela explique la forte augmentation du nombre de développeurs et d'applications créées. L'utilisation de Twitter s'effectue, par exemple, à plus de 60 % par l'intermédiaire d'api et d'applications tierces. Ce phénomène n'est pas limité aux applications grand public. Les utilisateurs de l'entreprise qui sont à l'aise sur le plan technique - en dehors de l'informatique traditionnelle - développent des applications de gestion à l'aide d'api pour entreprise. Une fois qu'une application est devenue populaire, le service informatique n'a d'autre choix que de la prendre en charge. REST, JSON et OAuth ne sont pas égaux en matière d'interopérabilité ; travailler à la médiation s'avère plus que jamais nécessaire. Figure 2 : Explosion des interfaces applicatives pour les applications d'entreprise Page 6

7 Bring-Your-Own-Standard Le problème des standards ouverts a toujours résidé dans leur trop grand nombre. Le modèle SOA (Service Oriented Architecture) est, par exemple, associé à une longue liste de WS-* et autres standards. Or, ces derniers présentent souvent des parties communes, ce qui peut rendre le choix difficile. Chacun possède néanmoins ses particularités. Bien que le déploiement n'ait rien d'anecdotique, l'usage d'un standard permet une interopérabilité quasiment garantie. Cette tendance s'est inversée avec le WOA (Web Oriented Architecture). Il n'existe actuellement qu'un nombre réduit de standards pour le WOA ; REST, JSON et OAuth s'étant rapidement imposés de fait. En raison de leur définition minimaliste, ces standards laissent une grande place à l'implémentation individuelle. Ainsi, REST correspond en réalité à un style d'implémentation avec des modèles de bonnes pratiques concurrents. Autrement dit, le WOA permet à chaque entreprise d'introduire son standard personnel. Ainsi, deux entreprises utilisant les standards REST, JSON et OAuth devront tout de même réaliser une médiation pour permettre l'interopérabilité de leurs API. Architecture applicative traditionnelle Malheureusement, l'architecture applicative et l'infrastructure de distribution actuelles s'avèrent en décalage avec cette évolution de l'usage des applications. Dans une architecture traditionnelle, à trois niveaux, une application est déployée sur un serveur d'application, qui se connecte à une base de données au niveau du backend et à un serveur Web au niveau du frontend. En règle générale, les applications : sont volumineuses, complexes et gèrent intégralement l'état d un traitement ; comportent une interface utilisateur Web unique ; comportent un seul modèle de contrôle d'accès ; ne disposent pas d'un système cohérent de mise à disposition d'api. Les services SOA afférents se caractérisent par : Grâce aux API, proposez de nouveaux services via les canaux mobiles et Web, intégrés aux applications existantes de l'entreprise. leur approche bas niveau et leur forte granularité ; leur orientation méthode et transaction ; leur logique de conception dans la perspective d'une réutilisation en mode SOA ; l'aspect non-trivial de leur utilisation. Page 7

8 Figure 3 : Architecture applicative traditionnelle à trois niveaux Les applications d'entreprise de grande envergure, tels que les progiciels ERP, sont pires encore dans le sens où leur aspect monolithique se conjugue au manque d'interfaces utilisables. Les intégrations inter-entreprises (B2B) et interapplications (A2A) reposent généralement sur des infrastructures SOA et d'intégration d'applications à grande échelle. Certains éditeurs de solutions ERP, notamment SAP et Oracle, ont ajouté aux API existantes des interfaces REST limitées, mais ces API ne correspondent souvent qu'à des versions REST des services SOA de bas niveau. Elles sont dépourvues des fonctions de sécurité et d'audit qui permettraient de les utiliser sans infrastructure de support. Constituez une architecture de déploiement d'applications agile en ajoutant un niveau de distribution des services métiers au dessus de l'infrastructure existante. Nouvelle génération d architecture applicative Le changement pour des applications mobiles et en mode cloud s inscrit dans la durée. Les progrès incessants des nouvelles technologies mobiles dans des domaines tels que l'automobile ou les objets intelligents ne font qu accroître le défi que représente ce phénomène. Les entreprises qui ne sauront pas suivre le rythme de ces évolutions accuseront une perte de compétitivité sur tous les fronts. Maintenir l'infrastructure applicative existante continuellement en phase avec les évolutions technologiques serait trop onéreux, trop lent et les conséquences impacteraient trop de systèmes. Certains ajouteront que l'infrastructure applicative n'a pas à suivre les tendances volatiles du cloud computing et de la mobilité. L'infrastructure applicative existante est au cœur du métier de l'entreprise, joue un rôle critique et contient d'énormes volumes de données. Des perturbations trop fréquentes de cette infrastructure fondatrice peuvent déstabiliser l'entreprise et freiner sa bonne marche. Une architecture plus innovante est requise pour la livraison d applications, une architecture qui permette de combler le fossé entre l'infrastructure héritée et l'évolution incessante du monde de la mobilité et du cloud computing. Dans ce contexte, la solution consiste à adopter une infrastructure applicative de nouvelle Page 8

9 génération, constituée de deux niveaux : un niveau de services d'infrastructure (IS) et un niveau de Distribution des Services d'entreprise (BSD Business Services Delivery). Figure 4 : Architecture applicative de nouvelle génération Niveau Services d'infrastructure (IS) Proposez de nouveaux services d'entreprise rapidement à l'aide d'api afin de capitaliser sur les opportunités du marché. Le niveau IS est constitué des ressources du backend qui incluent les services, les interfaces des applications et les données. La plupart de ces ressources existent déjà sous des formes reflétant différentes époques technologiques et proposant un niveau d'accessibilité et de disponibilité variable. Cette couche de l'infrastructure doit être stable car elle est relative au cœur de l'activité de l'entreprise qui subit peu de modifications. Avec l'ajout d'un niveau BSD, les données et les services existants peuvent facilement supporter la création de nouveaux services d'entreprise. Le niveau IS doit rester la propriété des groupes fonctionnels et des groupes gérant l'infrastructure applicative. Pour rendre le niveau IS plus flexible afin qu il apporte un meilleur support au niveau BSD, les entreprises doivent poursuivre une stratégie de virtualisation de l'ensemble des ressources de type services et données. Les services doivent être rendus accessibles par l'intermédiaire d'un cloud de services et les sources de données par l'intermédiaire d'un cloud de données. Le cloud de services et le cloud de données deviennent des bibliothèques de fonctionnalités stratégiques pouvant être assemblées pour créer de nouveaux services d'entreprise. Ils doivent rester indépendants des plates-formes applicatives. Le niveau BSD est responsable de la transformation des interfaces du niveau IS pour chacune des plates-formes applicatives prises en charge. Le cloud de services et le cloud de données doivent utiliser de façon standard un petit ensemble de protocoles d'interface internes afin de rendre leur consommation plus simple par le niveau BSD. Les entreprises qui ont déployé une infrastructure SOA étendue peuvent légitimement utiliser les protocoles SOAP et XML comme standard d accès à leurs services dans le cloud. Bien que le niveau BSD puisse utiliser les ressources existantes de type services et données, deux modifications à long terme du niveau IS sont vivement recommandées en vue d'une évolutivité plus poussée : (1) transférer la gestion Page 9

10 des états du cloud de services vers le cloud de données et (2) adopter un contrôle d'accès basé sur attributs. Dans la mesure où les utilisateurs peuvent accéder aux mêmes services via différentes applications et où chaque application peut utiliser les services différemment, la gestion des états par le cloud de services peut s'avérer problématique pour les scénarios d'accès multi-applications. Transférer la gestion des états au cloud de données et conserver un cloud de services sans état évite de devoir ajouter des logiques complexes dans le cloud de services ou dans le niveau BSD à la seule fin de prendre en charge des scénarios impliquant plusieurs platesformes. Étant donné que les applications peuvent également présenter des modèles de contrôle d'accès différents, la décision relative au contrôle d'accès doit être déléguée au niveau BSD. Le rôle du niveau IS est de fournir les attributs et les règles basées sur ces attributs. Ces règles sont ensuite interprétées par le niveau BSD à l'aide de technologies autorisant une gestion fine des autorisations. La classification des données, le code professionnel et la localisation sont des exemples typiques d'attributs utilisés dans les règles de contrôle d'accès. Le niveau Distribution des Services d'entreprise (BSD) Assurez la gestion, la distribution et la sécurité des API à l'aide d'un serveur d'api. Le niveau BSD, dédié à la distribution agile des services d'entreprise, constitue une nouveauté. Il est rattaché aux fonctions responsables de la mise à disposition des solutions destinées à l'utilisateur final, comme la gestion des produits, le marketing, les ressources humaines et la gestion de la chaîne logistique. Le niveau BSD est conçu dans une optique d'agilité; il est capable de soutenir le rythme d évolution beaucoup plus élevé des nouvelles plates-formes technologiques, et les changements imposés par des modèles économiques émergents, des évènements et le cycle de vie des affaires. Il permet aux entreprises de délivrer rapidement des services opérationnels pour tirer parti des opportunités du marché. Le niveau BSD est constitué de deux couches : (1) la couche de présentation aussi appelée interface utilisateur et (2) la couche API. La couche de présentation est en interaction directe avec l'utilisateur final. Elle peut faire appel aux technologies Internet standard ou à des technologies spécifiques aux plates-formes (ios et Android, par exemple) pour améliorer l expérience utilisateur et la conception de l'application. De nombreux outils de développement d'applications sont disponibles et facilitent la création de la couche de présentation. Cette couche doit contenir aussi peu de logique métier que possible afin de supporter efficacement de multiples plates-formes. La couche API fournit les fonctions métier à l'application. Elle exploite les ressources du niveau IS et des API tierces pour proposer des services d'entreprise tels que le suivi des colis ou à la génération de devis d'assurance. La couche API est également responsable de la gestion, de la distribution et de la sécurité des Page 10

11 API. Ces fonctions sont requises pour distribuer les API de façon rapide, cohérente et sûre. Cette couche API peut être créée à l'aide d'un produit tel que l'api Server, ou bien par l assemblage de plusieurs composantes telles que des gateways, des ESB (Enterprise Service Bus), des CSB (Cloud Service Broker) et des portails de gestion d'api. Un serveur d'api est une plate-forme complète, spécifiquement conçue dans l'objectif de gérer, distribuer et protéger les API de tous types. Ce serveur doit posséder les six catégories de fonctionnalités suivantes : Distribuez les API de façon rapide, cohérente et sûre en vous appuyant sur un serveur d'api. Transformation des API Contrôle et gouvernance des API Sécurité des API Surveillance et reporting des API Gestion du cycle de vie de développement des API Administration des API Figure 5 : Le serveur d'api relie les systèmes backend aux services frontend d'entreprise Dans la section qui suit, nous allons examiner en détail ces fonctions clés. Fonctions clés du serveur d'api Transformation des API Un serveur d'api permet de lier des protocoles, des messages et des jetons afin d'établir une communication entre des API normalement incompatibles. La transformation englobe les trois domaines clés suivants : (1) transformation des protocoles et des messages, (2) négociation et (3) orchestration. Page 11

12 Transformation des protocoles et des messages Utilisez le serveur d'api pour échanger des API tierces et créer des services d'entreprise novateurs. L'une des principales fonctions du serveur d'api dans l'architecture recommandée ci-dessus consiste à lier les protocoles incompatibles entre le cloud de services et la couche de présentation. Les services existants du backend se présentent sous différents protocoles, qu'il s'agisse d'api récentes utilisant REST et JSON, de Web services utilisant SOAP et XML, JMS, TCP, différentes variétés de protocoles B2B basés sur FTP et bien d'autres. Le serveur d'api doit proposer un ensemble d'options de transformation bidirectionnelles. Pour les transformations directes simples du type XML-JSON et SOAP-REST, le serveur d'api doit proposer des opérations préconfigurées. Pour les transformations spécifiques, le serveur d'api doit fournir des politiques configurables. Pour apporter plus de souplesse, il est souhaitable que le serveur d'api prenne en charge les transformations personnalisées à l'aide de langages de script courants, tels que JavaScript, Groovy, Jython et Ant. Négociation d'api Une entreprise consomme autant d'api qu'elle en distribue. Les API tierces peuvent être destinées à l'usage interne ou être intégrées aux services métiers. Selon leur provenance, les API utilisent différents protocoles et mécanismes d'authentification. Les entreprises peuvent demander à ce que chaque application et développeur d'application gèrent les différents protocoles, standards de sécurité et artefacts, mais cette approche s avère inefficace en termes de sécurité et d'évolutivité. Il s'avère préférable d'utiliser un serveur d'api pour gérer les besoins sécuritaires et protocolaires des API sources. Ainsi, une API Suivi_de_colis utilise les API sources de FedEX, UPS et DHL. Lorsque l'api Suivi_de_colis est appelée pour suivre un colis FedEx, le serveur d'api traduit l'appel de l'api dans le protocole utilisé par FedEx, insère le jeton d'authentification FedEx dans le message, puis route l'appel de l'api vers le serveur d'api FedEx. Le serveur d'api exécute ces tâches de négociation en arrière-plan, de façon transparente pour le client qui utilise l'api Suivi_de_colis. Du point de vue de l'entreprise, l'utilisation du serveur d'api en tant que gestionnaire des échanges permet de réduire le nombre d'interfaces supportées par ses applications. Le serveur d'api constitue également le seul référentiel d'artefacts de sécurité comme les jetons, les clés et les certificats.. Page 12

13 Figure 6 : Environnement graphique de développement pour l'orchestration des API Orchestration des API Créer un nouveau service métier revient à concevoir une combinaison de fonctionnalités tierces et internes existantes pour répondre à un besoin spécifique de l'entreprise. Pour être en mesure de répondre aux besoins du marché et de distribuer de nouveaux services en faisant preuve d'agilité, l'entreprise doit être capable d'orchestrer des API existantes afin de créer des API pour applications composites (mash-ups). Le serveur d'api propose des fonctions d'orchestration pour agréger et manipuler les données et fonctions disponibles via les API sources. Optez pour un serveur d'api doté d'un environnement de développement convivial permettant d'orchestrer les API par glisser-déplacer. Pour les orchestrations complexes, vous pouvez envisager de compléter le serveur d'api par des technologies de type ESB (Enterprise Service Bus) ou des outils de workflow BPEL (Business Process Execution Language). Contrôle et gouvernance des API Le serveur d'api permet aux entreprises d'exercer un contrôle en temps réel sur les performances des API à l'aide de politiques d'utilisation qui simplifient le suivi et le respect des obligations contractuelles et des bonnes pratiques de gouvernance. Le contrôle et la gouvernance englobent les trois domaines clés suivants : (1) la qualité de service, (2) le routage et (3) le niveau de service. Qualité de Service (QoS) La fonctionnalité proprement dite d'une API constitue un aspect secondaire ; pour être efficace, une API doit avant tout être distribuée avec une qualité constante. Les développeurs d'applications et les utilisateurs se détourneront rapidement d'api lentes et peu fiables. Le serveur d'api assure la surveillance et la gestion de la qualité de service pour que la distribution des API s'effectue dans les meilleures conditions de performances, de disponibilité et d'évolutivité. Capable de suivre les performances des API en temps réel, le serveur d'api émet des alertes en fonction Page 13

14 des seuils de qualité de service, mesure cette qualité et génère des rapports la concernant. Il est possible de configurer des mesures correctives visant à augmenter la qualité de service sous forme de politiques d'utilisation. Ces mesures peuvent consister à mesurer et réguler plusieurs API et clients d'api, ou encore à les diriger vers d'autres datacenters et serveurs backend afin d'optimiser la charge et la proximité. Utilisez le serveur d'api pour suivre et contrôler la performance et la disponibilité des API afin de garantir la qualité du service. Figure 7 : Tableau de bord de suivi de la qualité de service des API Routage Les appels d'api doivent faire l'objet d'un routage pour différentes raisons. Le routage peut contribuer à optimiser la qualité de service, à appliquer un contrat de niveau de service, à tester des services, à créer de la redondance et à augmenter les capacités. Le serveur d'api peut gérer le routage des API à l'aide d'une politique configurable. Les politiques de routage peuvent être statiques ou dynamiques. Les politiques dynamiques permettent de déduire des attributs tels que l'identité du client, le type de message, l'état du réseau et la géolocalisation. Le routage peut avoir une importance cruciale pour les API qui nécessitent des performances très élevées, notamment dans le domaine des échanges et règlements financiers, ou pour les API qui transmettent d'importants volumes de données, comme les catalogues de produits, les médias et les jeux vidéo. Niveau de service Les services d'entreprise peuvent être proposés dans différents niveaux de service. Les contrats de niveau de service (SLA) doivent être contrôlables et applicables au niveau des API. Le serveur d'api mesure les performances des API et utilise ces données pour appliquer et contrôler les niveaux de service. Dans la mesure où le serveur d'api est le point de terminaison de l'api du point de vue de l'application, le niveaux de service mesuré au niveau du serveur d'api est celui qu'a connu l'application, après déduction du temps de réponse du réseau. Outre la surveillance et l'évaluation, le serveur d'api peut également appliquer des règles en fonction du SLA pour mesurer l'utilisation des API et réguler leurs performances. La régulation peut reposer sur l'utilisation cumulée au cours d'une période (allocation mensuelle, par exemple) ou sur le nombre maximal de connexions parallèles. Une fois que le quota est atteint ou peu de temps avant, le Page 14

15 serveur d'api peut émettre des alertes, appliquer des règles de dépassement ou simplement bloquer l'accès. Le serveur d'api protège les API contre les attaques, l'accès non autorisé et les fuites de données. Figure 8 : Exemple des différentes offres de niveau de service proposées par Dun & Bradstreet Sécurité des API Un serveur d'api assure la sécurité intégrale des API, notamment (1) la sécurité de l'interface pour la protection contre les attaques, (2) le contrôle d'accès pour éviter tout accès non autorisé et (3) la sécurité des données pour éviter les fuites de données sensibles. Sécurité de l'interface Le serveur d'api offre une protection par pare-feu au niveau message pour les API. Il analyse les en-têtes, les messages et les pièces jointes afin de détecter et bloquer les attaques. Le niveau de protection offert s'avère nettement supérieur à celui d'un pare-feu réseau. Voici des exemples d'attaques courantes bloquées par le serveur d'api : Attaques par déni de service Attaques par injection de commandes Code malveillant, virus Scan et analyse (sniffing) Usurpation d'identité et fraude Collecte de données Escalade des privilèges Reconnaissance Le serveur d'api peut également limiter l'utilisation aux seules méthodes autorisées, comme certains verbes HTTP. Le serveur d'api exécute la validation des schémas XML et JSON pour éviter tout problème de compatibilité sur la ligne et d'éventuelles attaques par empoisonnement du schéma. Page 15

16 Contrôle d'accès Le serveur d'api permet un accès fédéré sécurisé aux API dans l'écosystème de partenaires. L'accès non autorisé représente le risque de sécurité et de conformité le plus élevé pour les API aussi bien que pour les applications. Le serveur d'api constitue le point d'application des politiques pour l'authentification et l'autorisation des API. Il propose des intégrations préconfigurées avec les principales plates-formes de gestion des accès et des identités (IAM), au rang desquelles CA, IBM, Oracle et RSA. Il enrichit également ces plates-formes IAM de capacités SAML, de fédération OAuth, d'autorisation à granularité fine et d'authentification des terminaux et des applications. Grâce à ces fonctions avancées, le serveur d'api permet d'utiliser une plate-forme d'entreprise IAM afin de contrôler l'accès au niveau utilisateur/navigateur et trafic des API. Le serveur d'api assure également la sécurité du stockage et l'administration des artefacts de sécurité utilisés pour l'authentification et la signature (clés, jetons et certificats). Optez pour des serveurs d'api intégrés avec des autorités de certification (CA) et des modules de sécurité matérielle (HSM) en vue de la compatibilité avec l'infrastructure de sécurité existante. Figure 9 : Exemple de politique de sécurité et bibliothèque de méthodes d'authentification et d'autorisation Sécurité des données Les API peuvent transmettre des données sensibles telles que le numéro de carte de crédit et le numéro de sécurité sociale. Par conséquent, elles sont souvent soumises à des obligations de conformité réglementaire (PCI DSS, confidentialité et conservation des données, par exemple). Le serveur d'api détecte non seulement les données sensibles dans les documents, mais aussi dans les emplacements où elles peuvent être intégrées sous forme d'identifiants et d'attributs, comme les en-têtes, les chaînes de requête et les noms de ressources. Lorsque des données sensibles sont détectées, le serveur d'api peut bloquer, mettre en quarantaine, supprimer, masquer, chiffrer ou marquer le message selon les règles. Le serveur d'api peut également faire office de point de terminaison SSL pour la communication sécurisée des API. Page 16

17 Surveillance des API et compte-rendu Le serveur d'api surveille les opérations des API et recueille des données afin de satisfaire aux obligations de compte-rendu et de conformité réglementaire. Il génère également des rapports sur l'utilisation des API pour contribuer à la création d'analyses de gestion. La surveillance et les compte-rendus disponibles sur le serveur d'api englobent les trois fonctions clés suivantes : (1) audit et journalisation, (2) surveillance et alerte et (3) analyses. Audit et journalisation Dans le cadre du respect des obligations de gouvernance et de conformité réglementaire, le serveur d'api collecte un journal d'audit complet des transactions d'api. Les API manipulent des transactions de gestion stratégiques et transmettent des données sensibles. Les transactions des API doivent être journalisées pour que l'entreprise dispose d'un journal d'audit, d'une preuve de conformité réglementaire et d'un enregistrement d'archive. Le serveur d'api doit offrir une grande souplesse dans la configuration des données à recueillir, du moment auquel effectuer cette opération et du mode de journalisation des données collectées. Il doit assurer le stockage sécurisé des données et journaux d'audit, avec le chiffrement et le contrôle d'accès voulus. Parallèlement à cela, les données d'audit doivent rester accessibles à des fins de compte-rendu ou être adressées à des outils de surveillance du système et de gestion des journaux. Figure 10 : Outil de suivi et de journalisation des transactions Surveillance et alertes Il arrive que des API soient intégrées à une infrastructure stratégique. Lorsque ces API cessent de fonctionner, l'activité peut s'arrêter, avec une perte de chiffre d'affaire à la clé. Le serveur d'api fournit aux administrateurs informatiques les outils nécessaires au suivi des transactions des API et de l'infrastructure du serveur lui-même. Les outils de surveillance des API et du système en temps réel peuvent alerter les administrateurs en cas d'exceptions ; ils procurent également une visibilité en temps réel du flux de trafic des messages pour faciliter le débogage. Un outil de surveillance des transactions contribue au suivi des transactions de bout en bout et au débogage des exceptions aux règles à l'aide de fonctionnalités de recherche exploratoire des étapes de politique individuelles. Page 17

18 Figure 11 : Surveillance en temps réel du trafic des API et des serveurs Analyses L'interface de développement par glisser-déplacer du serveur d'api permet de créer des API et des règles sans développer de code. Le serveur d'api occupe une position privilégiée pour recueillir des données et générer des rapports sur l'utilisation de toutes les API. Il propose, par exemple, des statistiques concernant les API utilisées, leur niveau d'utilisation, le moment auquel elles sont utilisées et l'identité des utilisateurs. Les données d'analyse et les graphiques sont accessibles via une interface utilisateur Web classique ; les informations peuvent être envoyées automatiquement par courriel sous forme de rapports au format PDF. Pour les besoins avancés en matière de compte-rendu, le serveur d'api peut transmettre les données à des outils de supervision, permettre leur accès via une API REST ou autoriser l'accès direct à une base de données de compte-rendu à l'aide d'un outil de reporting du marché. Cycle de vie de développement des API Les API possèdent de nombreux points communs avec les applications, notamment leur cycle de vie. Le cycle de vie des API recouvre les phases de développement, test, déploiement, distribution, administration et surveillance. Le (1) développement, (2) le test et la (3) distribution représentent les trois phases de développement clés du cycle de vie des API. L'administration (exploitation) des API constitue la partie la plus longue et importante du cycle de vie. La phase d'administration est abordée dans la section qui suit. Développement des API Les API demandent à être développées, au même titre que les règles qui en régissent le fonctionnement. Il s'avère extrêmement rare de trouver des API sources prêtes à l'emploi sans un certain niveau de transformation, de réorganisation et d'orchestration. Par ailleurs, chaque entreprise doit créer des jeux de règles à affecter aux API afin de satisfaire à ses obligations opérationnelles de conformité réglementaire et de sécurité. Pour bénéficier d'un processus de développement aussi simple que possible des API et des règles, optez pour un Page 18

19 serveur d'api doté d'un environnement de développement par glisser-déplacer. Idéale pour tout nouveau développement, la visualisation sous forme de diagramme de la création des API et des règles joue un rôle plus important encore du point de vue de la maintenance. Un bon serveur d'api doit proposer une bibliothèque de tâches étendue, pouvant être facilement reliées les unes aux autres pour créer des règles. Figure 12 : Développement d'api par glisser-déplacer Test des API Utilisez le serveur d'api pour gérer et automatiser la migration des API, règles et configurations vers d'autres environnements. Le test des API constitue une tâche cruciale qui intervient avant, pendant et après les phases de développement. Il existe de nombreux outils de test d'api open source et commerciaux. Idéalement, le serveur d'api doit proposer un outil de test intégré pour permettre : de tester les API et les fonctions des règles ; de définir le débit et la latence des API ; de tester les clients d'api ; d'exécuter un test de charge et d'évaluer les performances ; de simuler des attaques pour identifier les vulnérabilités des API ; d'exécuter des contrôles d'intégrité continus pendant la production. Distribution des API La distribution des API se compose de deux aspects très différents : (1) la migration et (2) la promotion et l'activation. La migration consiste à transférer les définitions de services, règles et configurations des API vers d'autres environnements dans la séquence suivante : Developpement Test Déploiement Production Page 19

20 La procédure de migration/promotion peut différer à chaque étape. La procédure de promotion de la génération jusqu'à la production peut s'avérer particulièrement stricte, régie par les politiques opérationnelles du centre de calcul. Le serveur d'api doit permettre de créer des packages de migration, de gérer les différences des variables d'environnement, de créer des versions et de gérer le rollback. Les administrateurs de datacenter privilégient (ou imposent) souvent la migration par script. Dans ces conditions, optez pour un serveur d'api prenant en charge les langages de script usuels de votre entreprise (Jython et Ant, par exemple). Le serveur d'api est une plate-forme d'administration unifiée pour les API de toutes sortes. Le second aspect de la distribution des API correspond à la promotion et à l'activation des API ouvertes. Les API ouvertes présentent la caractéristique d'être largement exposées aux développeurs externes à l'entreprise. Leur adoption nécessite une action pédagogique, une promotion par le marketing, la prise en charge du libre-service et le support de la communauté. Les équipes de marketing et de gestion partenaires utilisent souvent un portail de développeurs pour proposer ces services de promotion et d'activation des API ouvertes et recruter des développeurs externes ou de nouveaux distributeurs. Que le portail corresponde à un service commercial en mode cloud ou à une plate-forme personnalisée, le serveur d'api joue un rôle indispensable pour délivrer les services d'infrastructure du type intégration d'application, gestion des artefacts de sécurité, intégration de la gestion de l'identité et intégration des bases de données partenaire. Ces éléments s'ajoutent aux tâches d'administration de backoffice, également disponibles par le biais des serveurs d'api. Figure 13 : Exemple de portail développeurs par Google Administration des API Le serveur d'api prend en charge l'administration de tous les aspects liés au fonctionnement des API au quotidien. Ceci englobe l'administration au niveau du back-office des (1) API, politiques et serveurs (2) des clients d'api et (3) des transactions des API. Page 20