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 plus d'informations sur les proxys d'API, consultez la page 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 et, si nécessaire, rétablissez une révision précédente. Consultez la section Déployer des proxys d'API.
Pour commencer à développer vos proxys d'API avec Apigee, consultez la section 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érifier la fonctionnalité par le biais d'un test unitaire et manuel (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 la section Déployer des proxys d'API.
Pour commencer à développer vos proxys d'API localement à l'aide d'Apigee dans VS Code, consultez la page 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 la section À 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 lors de l'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 met en œuvre 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 cette fonctionnalité. Vous pouvez également écrire des scripts et du code personnalisés (tels que des applications JavaScript) qui étendent les fonctionnalités du proxy d'API et vous permettent d'innover 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 la page Qu'est-ce qu'une règle ?
Apigee est prêt à utiliser des règles 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 la page 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 affiner 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 votre API disponible pour les développeurs pendant le développement et le test de nouvelles fonctionnalités.
Déploiement de scripts à 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 automatisée et les font passer d'un environnement à un autre, lors 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 cet environnement 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 l'itération que sur les proxys d'API dans un environnement de test et d'apporter autant de modifications que nécessaire 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.
- Mappages de valeurs clés (KVM) : s'ils sont applicables à l'environnement, vous devez vous assurer que les conventions de dénomination permettent d'autoriser les proxys d'API à stocker des données sans nécessiter de modification de configuration lors de la promotion. Pour plus d'informations, consultez la section Utiliser des mappages clés/valeurs.
- URL cibles : il est courant que les proxys d'API appellent différentes URL de backend pendant les tests et la production. Vous pouvez créer des configurations TargetEndpoint indépendantes de l'environnement à l'aide des configurations TargetServer. Pour en savoir plus, consultez les pages suivantes :
- Équilibrage de charge sur les serveurs backend (développement dans le 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 la section 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 la section Conditions avec variables de flux.