Vous consultez la documentation Apigee Edge.
Accédez à la
documentation**Apigee X**. info
Apigee Edge est une plate-forme de développement et de gestion des API. En apposant aux services une couche proxy, Edge fournit une abstraction ou une façade pour vos API de services de backend et fournit une sécurité, une limitation du débit, des quotas, des analyses, etc.
Par exemple, vous pouvez regarder un webcast sur la manière dont Walgreens utilise les API et Apigee Edge pour fournir un écosystème d'applications riche pour le tirage photo, les recommandations et autres services.
Accélération numérique
Cette vidéo vous donne un bref aperçu de la manière dont Apigee vous aide à faire évoluer votre activité numérique.
Choisir entre la gestion des services et la gestion des API
Cette vidéo vous aide à comprendre les principales différences entre la gestion de services et la gestion des API.
Mettre à disposition vos services sur le Web
Aujourd'hui, les entreprises souhaitent mettre leurs services de backend à disposition sur le Web, afin que ces services soient utilisés par les applications exécutées sur les appareils mobiles et les ordinateurs de bureau. Une entreprise peut souhaiter exposer des services fournissant des informations sur le prix et la disponibilité des produits, des services de vente et de commande, des services de suivi des commandes, ainsi que tout autre service requis par les applications clientes.
Les entreprises exposent souvent des services sous la forme d'un ensemble de points de terminaison HTTP. Les développeurs d'applications clientes envoient ensuite des requêtes HTTP à ces points de terminaison. Selon le point de terminaison, le service peut ensuite renvoyer des données, au format XML ou JSON, vers l'application cliente.
Les applications clientes qui exploitent ces services peuvent être implémentées en tant qu'applications autonomes pour un appareil mobile ou une tablette, sous forme d'applications HTML5 s'exécutant dans un navigateur ou sous forme de tout autre type d'application pouvant envoyer une requête à un point de terminaison HTTP et consommer des données de réponse. Ces applications peuvent être développées et publiées par l'entreprise qui a exposé les services ou par des développeurs d'applications tiers qui utilisent des services accessibles au public.
L'image suivante montre ce type de modèle :
Étant donné que les fournisseurs proposent leurs services sur le Web, ils doivent s'assurer qu'ils ont pris toutes les mesures nécessaires pour sécuriser et protéger leurs services contre tout accès non autorisé. En tant que fournisseur de services, vous devez tenir compte des points suivants :
- Sécurité : comment allez-vous contrôler l'accès à vos services pour empêcher tout accès non autorisé ?
- Compatibilité : vos services fonctionneront-ils sur différentes plates-formes et appareils ?
- Mesurabilité : comment pouvez-vous surveiller vos services pour vous assurer qu'ils sont disponibles ?
- Monétisation : comment pouvez-vous suivre et facturer les clients pour l'accès à vos services ?
- Et bien d'autres considérations
Après la publication d'une application cliente qui accède à des services, le fournisseur de services est tenu de garantir que ces services continuent à fonctionner au fur et à mesure qu'ils ajoutent, modifient ou suppriment ces services. Le fournisseur de services doit également pouvoir informer les développeurs d'applications de toute modification apportée aux services, afin de s'assurer que les applications clientes restent synchronisées avec ces services.
Les développeurs d'applications clientes sont confrontés à des défis lorsqu'ils tentent d'exploiter des services de différents fournisseurs. De nombreuses technologies sont actuellement disponibles pour être utilisées par un fournisseur de services afin d'exposer ses services. La même application cliente peut devoir utiliser un certain mécanisme pour exploiter un service provenant d'un fournisseur, et un autre mécanisme pour exploiter un service provenant d'un autre fournisseur. Les développeurs d'applications peuvent même faire face à une situation dans laquelle ils doivent utiliser différents mécanismes pour exploiter des services du même fournisseur.
Rendre les services disponibles via Apigee Edge
Apigee Edge vous permet de fournir un accès sécurisé à vos services avec une API bien définie cohérente sur l'ensemble de vos services, quelle que soit la mise en œuvre du service. Une API constante :
- permet aux développeurs d'applications de consommer facilement vos services ;
- permet de modifier la mise en œuvre du service de backend sans affecter l'API publique ;
- vous permet de bénéficier des données analytiques, de la monétisation, du portail des développeurs et d'autres fonctionnalités intégrées à Edge.
L'image suivante montre une architecture avec Edge qui gère les requêtes des applications clientes vers vos services de backend :
Au lieu d'exploiter directement vos services, les développeurs d'applications accèdent à un proxy d'API créé sur Edge. Le proxy d'API fonctionne comme un mappage d'un point de terminaison HTTP accessible au public à votre service de backend. En créant un proxy d'API, vous permettez à Edge de gérer les tâches de sécurité et d'autorisation requises pour protéger vos services, ainsi que pour analyser, surveiller et monétiser ces services.
Étant donné que les développeurs d'applications envoient des requêtes HTTP à un proxy d'API plutôt qu'à vos services directement, les développeurs n'ont pas besoin d'en savoir plus sur la mise en œuvre de vos services. Le développeur a uniquement besoin de savoir ce qui suit :
- L'URL du point de terminaison du proxy d'API
- Tous les paramètres de requête, en-têtes ou paramètres de corps transmis dans une requête
- Tous les identifiants d'authentification et d'autorisation requis
- Le format de la réponse, y compris le format des données de réponse, tel que XML ou JSON
Le proxy d'API isole le développeur d'applications de votre service de backend. Par conséquent, vous êtes libre de modifier la mise en œuvre du service tant que l'API publique reste cohérente. En maintenant une cohérence de l'interface de l'API, les applications clientes existantes continuent de fonctionner quelles que soient les modifications apportées au backend.
Vous pouvez utiliser des règles sur le proxy d'API pour ajouter des fonctionnalités à un service sans avoir à modifier le service de backend. Par exemple, vous pouvez ajouter des règles à votre proxy pour effectuer des transformations et filtrer des données, ajouter des règles de sécurité, exécuter une logique conditionnelle ou un code personnalisé, et effectuer de nombreuses autres actions. Il est important de se rappeler que vous implémentez des règles sur Edge, et non sur votre serveur de backend.
Pour en savoir plus, consultez la page Comprendre les API et les proxys d'API.
Créer un produit d'API
Un proxy d'API est le point de terminaison HTTP sur Apigee Edge qui permet aux développeurs d'accéder à vos services de backend. Bien que cela soit possible, vous ne mettez généralement pas à disposition des proxys d'API individuels. À la place, vous regroupez un ou plusieurs proxys d'API dans un produit d'API.
Un produit d'API est un ensemble de serveurs proxy d'API associés à un forfait. Ce forfait peut définir des limites d'accès sur les proxys d'API, assurer la sécurité, autoriser la surveillance et l'analyse, et proposer des fonctionnalités supplémentaires. Les produits d'API sont également le mécanisme central utilisé par Edge pour l'autorisation et le contrôle des accès à vos API.
Vous êtes très flexible lors de la création de produits d'API. Par exemple, plusieurs produits d'API peuvent partager le même proxy d'API. La figure suivante illustre trois produits d'API. Notez que tous les produits autorisent l'accès au proxy d'API 3, mais que seul le produit A autorise l'accès au proxy d'API 1.
Vous pouvez définir différentes propriétés pour chaque produit d'API. Par exemple, vous pouvez proposer un produit d'API avec une limite d'accès faible, telle que 1 000 requêtes par jour, à un prix attractif. Vous publiez ensuite un autre produit d'API donnant accès au même proxy d'API, mais avec une limite d'accès beaucoup plus élevée, à un prix plus élevé. Vous pouvez également créer un produit d'API sans frais qui autorise l'accès en lecture seule à vos services, puis vendre un produit d'API aux mêmes proxys d'API qui autorisent l'accès en lecture/écriture.
Pour en savoir plus, consultez la page Gérer les produits d'API.
Autoriser une application côté client à accéder à votre produit d'API
Lorsque les développeurs d'applications décident d'accéder à vos services, ils doivent d'abord enregistrer leur application cliente auprès de votre produit d'API.
Lors de l'enregistrement, un développeur d'applications reçoit une clé API qu'il doit ensuite inclure dans chaque requête adressée à un proxy d'API inclus dans le produit d'API. Cette clé est authentifiée et, si l'authentification réussit, la requête est autorisée à accéder à votre service de backend.
Vous pouvez révoquer la clé à tout moment pour que l'application cliente n'ait plus accès à vos services. Vous pouvez également définir une limite de temps sur une clé de sorte que le développeur doive l'actualiser après un délai spécifique.
Vous choisissez comment gérer les requêtes d'enregistrement des développeurs pour accéder à vos produits d'API. En utilisant les services pour les développeurs Apigee Edge, vous pouvez automatiser le processus d'enregistrement ou vous pouvez utiliser un processus manuel pour contrôler l'accès.
Créer des produits d'API et les mettre à la disposition des développeurs
- Créez un ou plusieurs proxys d'API qui associent des URL accessibles au public à vos services de backend.
- Créez un produit d'API qui regroupe vos proxys d'API.
- Déployez les proxys d'API et les produits d'API.
- Indiquez à vos développeurs que le produit d'API est disponible.
Une fois que les développeurs d'applications sont au courant de la disponibilité de votre produit API, ils pourront :
- enregistrer leurs applications clientes dans votre produit d'API ;
- recevoir une clé API pour le produit d'API.
- Vous pouvez envoyer des requêtes à vos services via des proxys d'API (intégrés au produit d'API) et transmettre la clé API à chaque requête.
Composants d'Apigee Edge
Apigee Edge se compose d'environnement d'exécution, de surveillance et de données analytiques d'API, ainsi que de services de développement, qui ensemble fournissent une infrastructure complète pour la création, la sécurité, la gestion, et les opérations des API.
La figure suivante illustre les services Edge :
Environnement d'exécution d'API Edge
Les services d'API Apigee Edge sont axés sur la création et l'utilisation d'API, que vous créiez des proxys d'API en tant que fournisseur de services ou que vous utilisiez des API, des SDK et d'autres services pratiques en tant que développeur d'applications.
Le serveur de gestion des API fournit des outils permettant d'ajouter et de configurer les proxys d'API, de configurer des produits d'API et de gérer les développeurs d'applications et les applications clientes. Cela décharge de nombreux problèmes de gestion courants de vos services de backend. Lorsque vous ajoutez un proxy d'API, vous pouvez appliquer des règles au proxy d'API pour l'ajout de fonctionnalités de sécurité, de limitation du débit, de médiation, de mise en cache, etc. Vous pouvez également personnaliser le comportement de votre proxy d'API en appliquant des scripts personnalisés, en appelant des API et des services tiers, etc. Pour en savoir plus, consultez la page Comprendre les API et les proxys d'API.
Si vous êtes un développeur Node.js, vous pouvez ajouter facilement vos modules Node.js à Edge afin de créer des API et des applications composites, tout en bénéficiant des avantages offerts par Edge, de la transformation des messages à la sécurité, en passant par les données analytiques.
Surveillance et analyse Edge
Apigee Edge API Analytics fournit des outils puissants pour visualiser les tendances d'utilisation à court et long terme de vos API. Vous pouvez segmenter votre audience en fonction des meilleurs développeurs et applications, comprendre l'utilisation par méthode API pour savoir où investir, et créer des rapports personnalisés sur les informations au niveau de l'entreprise ou des opérations.
Lorsque les données transitent par Edge, plusieurs types d'informations par défaut sont collectés, y compris l'URL, l'adresse IP, l'ID utilisateur pour les informations d'appel d'API, la latence, les données d'erreur, etc. Vous pouvez créer des règles pour ajouter d'autres informations, telles que des en-têtes, des paramètres de requête et des parties d'une requête ou d'une réponse extraite de XML ou de JSON. Ces informations sont collectées de manière asynchrone à partir du flux réel de requête/réponse et n'ont donc aucun effet sur les performances de l'API.
L'interface utilisateur de gestion vous permet d'afficher plusieurs métriques et dimensions dans un navigateur, comme illustré dans la figure suivante :
Cependant, vous pouvez également accéder au service d'analyse et le contrôler via une interface de ligne de commande ou via les API RESTful. Consultez la page Présentation d'API Analytics pour en savoir plus.
Écosystème de développeurs Edge
Apigee Edge fournit des services de développement qui vous permettent ce qui suit :
- Gérer la communauté des développeurs d'applications qui utilisent vos services
- Travailler avec des développeurs internes et externes et formaliser les relations avec des modèles financiers
- Intégrer des développeurs et créer un portail des développeurs. Les développeurs d'applications se connectent à votre portail pour accéder à la documentation de l'API afin d'en savoir plus sur vos produits d'API accessibles au public et de gérer les clés API.
Chaque client Edge peut créer son propre portail des développeurs, dans le cloud ou sur site avec Apigee Edge for Private Cloud.
Apigee Edge vous permet de créer deux types de portails :
- Portail intégré pouvant être provisionné instantanément Consultez la page Créer votre portail intégré.
- Portail basé sur Drupal Consultez la page Créer un portail basé sur Drupal.
Monétisation
Les fonctionnalités de monétisation fournissent l'infrastructure et les relations financières nécessaires pour transformer votre communauté de développeurs en un véritable canal pour vos actifs numériques. Grâce à la monétisation, vous pouvez créer différents plans tarifaires qui facturent les développeurs pour l'utilisation de vos produits d'API ou vous permettent de payer les développeurs dans des scénarios de partage des revenus.
Les plans incluent des plans prépayés, des plans post-payés, des plans à tarif fixe, des plans à tarif variable, des plans "freemium", des plans adaptés à des développeurs spécifiques, des plans couvrant des groupes de développeurs, et plus encore. En outre, la monétisation inclut des fonctionnalités de reporting et de facturation.
Pour en savoir plus, consultez la page Présentation de la monétisation.
Versions d'Edge
Apigee Edge propose les versions suivantes :
- Cloud public : version SAAS hébergée dans laquelle Apigee gère l' environnement, ce qui vous permet de vous concentrer sur la création de vos services et la définition de leurs API
- Cloud privé : installation sur site dans laquelle vous contrôlez l'environnement matériel et êtes responsable de l'installation, de la mise à niveau, de la maintenance et d'autres processus administratifs.
Si vous êtes intéressé par notre version Apigee hybrid, consultez les rubriques Apigee X suivantes :
D'un point de vue fonctionnel, les versions Cloud public et Cloud privé sont très similaires. Toutefois, la version Cloud privé n'est pas compatible avec toutes les fonctionnalités de la version Cloud public. Les fonctionnalités non compatibles avec le Cloud privé incluent les suivantes :
- Cibles hébergées
- Extensions
- Portails de développeurs intégrés (Remarque : Les portails de développeurs basés sur Drupal sont compatibles)
- Surveillance des API
- Sense
Pour obtenir la liste des différences entre les versions, consultez la page Comparer les produits Apigee.
Il existe également des différences mineures entre les API, comme décrit dans Différences entre l'API Edge for Public Cloud et l'API Cloud privé.
Le Cloud public est compatible avec les comptes sans frais et payants. Le Cloud privé nécessite des comptes payants.
Pour une compatibilité totale avec une installation sur site, la version Cloud privé inclut des composants tels que le serveur de gestion Apigee, une base de données NoSQL Apache Cassandra, un serveur OpenLDAP, un routeur de messages et un processeur de messages.