Cette page s'applique à Apigee et à Apigee hybrid.
Consultez la documentation d'Apigee Edge.
Les sections suivantes récapitulent le cycle de vie du développement d'API à l'aide d'Apigee.
Développer des proxys d'API
Apigee accepte les options suivantes pour le développement itératif de proxy d'API :
Pour en savoir plus sur les proxys d'API, consultez Comprendre les API et les proxys d'API.
Développement cloud avec Apigee
Développez vos proxys d'API à l'aide des outils de débogage et de modification de proxy d'API fournis avec Apigee. Lorsque vous travaillez sur un proxy d'API, Apigee enregistre les itérations de votre configuration en tant que révisions.
Lorsque vous déployez un proxy d'API, vous choisissez une révision spécifique à déployer. En général, vous déployez la dernière révision. Si nécessaire, vous pouvez rétablir une révision précédente. Consultez Déployer des proxys d'API.
Pour commencer à développer vos proxys d'API avec Apigee, consultez Créer un proxy d'API simple.
Développement local à l'aide d'Apigee dans VS Code
Utilisez Apigee dans Visual Studio Code (VS Code) pour développer vos proxys d'API, et vérifiez la fonctionnalité par le biais de tests unitaires et manuels (par exemple, envoyer une requête et afficher les résultats).
Une fois la validation locale effectuée, déployez vos configurations de proxy d'API en tant qu'archives dans vos environnements Apigee. Consultez Déployer des proxys d'API.
Pour commencer à développer vos proxys d'API localement à l'aide d'Apigee dans VS Code, consultez Créer votre premier proxy d'API à l'aide d'Apigee dans VS Code.
Déployer des proxys d'API
Créez des environnements dans lesquels déployer des proxys d'API. La distinction entre différents environnements est arbitraire. Chaque environnement est simplement identifié par un ensemble différent d'adresses réseau (URL). L'objectif est de vous fournir un domaine dans lequel vous pouvez créer et vérifier les proxys d'API avant que l'API ne soit exposée à des développeurs externes. Pour en savoir plus, consultez À propos des environnements et des groupes d'environnements.
En déployant vos API dans plusieurs environnements, vous pouvez séparer le trafic entre les proxy d'API sur lesquels vous travaillez dans un environnement test et ceux qui sont accessibles via des applications externes pour exécution dans un environnement de production.
Apigee accepte les types de déploiement suivants dans un environnement :
| Type | Description |
| Proxy | Développez et testez vos proxys d'API dans vos environnements de développement Apigee, puis déployez-les dans les environnements de test et de production d'intégration Apigee. Consultez la section Déployer un proxy d'API. |
| Archive | Développez et testez vos proxys d'API programmables à l'aide d'Apigee dans VS Code. |
Ajouter des règles
Apigee vous permet de programmer le comportement de l'API sans écrire de code, à l'aide de règles. Une règle est comme un module qui implémente une fonction de gestion limitée et spécifique. Les règles vous permettent d'ajouter des types courants de fonctionnalités de gestion à une API de manière simple et fiable. Les règles fournissent des fonctionnalités telles que la sécurité, la limitation du débit, la transformation et la médiation, ce qui vous évite d'avoir à coder et à gérer vous-même ces fonctionnalités. Vous pouvez également écrire des scripts et du code personnalisés (comme des applications JavaScript) qui étendent les fonctionnalités du proxy d'API et vous permettent d'offrir des fonctions innovantes en plus des fonctionnalités de gestion de base compatibles avec les règles Apigee. Pour en savoir plus sur les règles Apigee, consultez Qu'est-ce qu'une règle ?
Apigee fournit des règles prêtes à l'emploi pour diverses fonctionnalités telles que la gestion du trafic, la sécurité, la médiation, ainsi que des règles d'extension. Pour afficher la liste complète des règles disponibles dans Apigee, consultez Présentation de la documentation de référence des règles.
Passer en production
Vous choisissez où déployer une API. Par exemple, vous pouvez promouvoir une révision dans un environnement de production pour permettre aux développeurs de commencer à utiliser votre API. En même temps, vous pouvez itérer plusieurs révisions dans un environnement local ou de test, où vous ajoutez des fonctionnalités ou affinez des règles. Lorsque vous êtes prêt, vous pouvez déployer la nouvelle révision dans l'environnement de production en remplaçant la révision existante dans cet environnement. Cette méthode vous permet d'avoir toujours une révision active de l'API disponible pour les développeurs, tandis que vous développez et testez de nouvelles fonctionnalités.
Écrire des scripts de déploiement à l'aide de l'API Apigee
Apigee fournit une API RESTful qui vous permet d'intégrer le déploiement de proxy d'API et la gestion au cycle de vie du développement logiciel (SDLC) de votre organisation. Par exemple, pour s'assurer que les exigences de sécurité, de fiabilité et de cohérence sont respectées, une utilisation courante de l'API Apigee consiste à écrire des scripts ou du code qui déploient des proxys d'API de manière programmatique et les promeuvent d'un environnement à un autre, dans le cadre d'un processus automatisé plus vaste.
Pour en savoir plus, consultez la page API Apigee.
Gérer les ressources de l'environnement
Les environnements fournissent également une séparation des données et des ressources. Par exemple, vous pouvez configurer différents caches dans vos environnements test et production, auxquels seuls les proxys d'API exécutés dans l'environnement concerné peuvent accéder. En outre, les clés API générées dans un environnement de test ne sont pas valides dans un environnement de production, et inversement.
Pour mieux contrôler la promotion, il est recommandé de n'effectuer des itérations sur les proxys d'API que dans un environnement de test, et de n'apporter que les modifications nécessaires aux proxys d'API déployés dans un environnement de production.
Pour ce faire, vous devez vous assurer que certaines ressources associées à chaque environnement sont configurées de manière à rester statique dans une configuration de proxy d'API.
- Pour en savoir plus, consultez Utiliser des mappages clé-valeur.
- URL cibles : il est courant que les proxys d'API appellent des URL de backend différentes pendant les tests et la production. Vous pouvez créer des configurations TargetEndpoint indépendantes de l'environnement à l'aide de configurations TargetServer. Pour en savoir plus, consultez
- Équilibrage de charge sur les serveurs backend (développement cloud)
- Configurer les serveurs cibles (développement local)
- Cibles ServiceCallout : les appels de service peuvent utiliser différentes cibles en fonction de l'environnement si, par exemple, un appel de service dans l'environnement de test utilise un service de démonstration. Consultez Règle ServiceCallout.
Pour rendre les configurations de proxy d'API indépendantes de l'environnement, vous pouvez également utiliser des instructions conditionnelles.
Les instructions conditionnelles créées à l'aide de la variable environment.name peuvent être utilisées pour évaluer l'environnement actuel avant d'appliquer une règle ou avant d'acheminer le trafic vers une URL sur le backend. Pour en savoir plus, consultez Conditions avec variables de flux.