Cette page s'applique à Apigee et à Apigee hybrid.
Consultez la documentation d'Apigee Edge.
Une organisation est le conteneur de niveau supérieur dans Apigee. Elle contient tous les proxys d'API et les ressources associées. Bien que le reste de cet article explique plus en détail les organisations, voici quelques points pratiques :
- Une fois une organisation créée, vous ne pouvez plus la renommer.
- Le nom de votre organisation figure dans l'URL de l'interface utilisateur d'Apigee. Exemple :
https://apigee.google.com/organizations/ORG_ID
- Lorsque vous effectuez des appels à l'aide de l'API Apigee, l'organisation constitue une partie obligatoire du chemin d'accès dans la plupart des appels. Par exemple, la requête
curl
suivante renvoie la liste de tous les proxys d'API d'une organisation à l'aide de l'API Organizations :curl https://apigee.googleapis.com/v1/organizations/YOUR_ORG_ID/apis
- Bien que vous ayez créé une seule organisation, vous pouvez appartenir à d'autres organisations en tant qu'utilisateur ou qu'administrateur disposant d'autorisations spécifiques. Vous pouvez passer à une autre organisation, comme décrit dans la section Passer d'une organisation à une autre.
- Une organisation Apigee n'est pas identique à une organisation Google Cloud. En cas d'ambiguïté, le présent document doit préciser que l'"organisation" est une organisation Apigee.
Vidéo : Regardez une courte vidéo pour découvrir comment les organisations prennent en charge une architecture mutualisée pour la gestion des API.
Types d'organisations
Il existe deux types d'organisations :
Payante : organisation permanente avec évolutivité complète. Également appelée organisation de production. Les organisations payantes incluent celles créées dans le cadre d'un abonnement ou d'un modèle de paiement à l'usage d'Apigee.
Évaluation : organisation temporaire en libre-service permettant de tester Apigee. Ces organisations d'évaluation sont limitées dans le temps et ne disposent pas de l'évolutivité et de la flexibilité des organisations de production.
Consultez également la section Comparaison des organisations d'évaluation et payantes.
Durée de vie de l'organisation d'évaluation
Les organisations d'évaluation ont une durée de vie limitée :
- Jour 0 : l'organisation d'évaluation est créée.
- Jour 30 : Google vous envoie une notification par e-mail vous informant de l'expiration à venir de l'organisation d'évaluation.
- Jour 60 : Google supprime l'organisation d'évaluation.
Composants de l'organisation
L'image suivante montre les principaux composants du modèle organisationnel d'Apigee. Ce modèle définit la manière dont vos API, produits d'API, applications et développeurs d'applications sont tous liés dans Apigee.
Ce modèle n'affiche pas toutes les fonctionnalités d'Apigee, mais il est conçu pour vous montrer que l'organisation est la racine d'un déploiement.
Le tableau suivant décrit plus en détail les composants du modèle organisationnel :
Composant | Description |
---|---|
Organisation |
Chaque organisation Apigee appartient à un seul projet Google Cloud et un projet ne peut contenir qu'une seule organisation. Une organisation contient des environnements, des proxys d'API, des produits d'API, des packages d'API, des applications et des utilisateurs. Les titulaires de compte ne sont pas limités à une seule organisation. Certains titulaires de compte peuvent définir ou être membres de plusieurs organisations qui prennent en charge différentes communautés de développeurs d'applications. |
Environnements et groupes d'environnements | Un environnement est un environnement logiciel isolé, au sein d'une organisation, dans lequel vous déployez des proxys d'API. Vous pouvez créer plusieurs environnements au sein d'une organisation. Un groupe d'environnements est un groupe d'environnements avec un ou plusieurs noms d'hôte. Le nom d'hôte fait partie de l'URL utilisée pour appeler les proxys d'API déployés dans n'importe quel environnement du groupe d'environnements. |
proxy d'API |
Un proxy d'API est une interface entre les requêtes entrantes et les services de backend. L'entité de proxy contient les instructions et stratégies exécutées par Apigee lors du traitement des requêtes des clients et des réponses du backend. |
Produit d'API |
Entité permettant de publier des API. Les produits d'API sont publiés sur le portail des développeurs afin que les développeurs externes puissent les utiliser. Un produit d'API présente une interface permettant d'accéder à une ou plusieurs API publiées. L'interface (qui peut être décrite à l'aide d'une spécification OpenAPI) peut inclure une combinaison d'une ou plusieurs des requêtes API traitées par un ou plusieurs proxys d'API. Les utilisateurs d'une organisation créent des produits d'API. Ce faisant, ils peuvent associer des métadonnées arbitraires à chaque produit d'API. Un type de métadonnées couramment utilisé peut définir un forfait de service, qui peut lui-même spécifier des limites d'accès sur les appels d'API, définir des exigences de sécurité, autoriser la surveillance et l'analyse, et fournir des fonctionnalités supplémentaires. Apigee collecte des données pour analyse sur les produits d'API. |
Fournisseur d'API |
La personne ou l'entité qui crée et gère les proxys et les produits d'API. Les développeurs d'applications clientes accèdent à ces API publiées. |
Développeur d'applications |
Une organisation contient un ou plusieurs développeurs qui créent les applications utilisant les API (publiées sous forme de produits d'API) définies par votre organisation. Les développeurs utilisent des API, mais ne peuvent pas créer d'API ni effectuer d'autres actions dans l'organisation. Les développeurs peuvent être internes à votre entreprise, être des partenaires ou être des développeurs externes qui paient ou non pour accéder à vos API. Vous pouvez considérer les développeurs comme des clients qui utilisent vos API. Les développeurs doivent être enregistrés dans votre organisation pour pouvoir enregistrer une application et recevoir une clé API afin d'accéder à vos API. En tant que fournisseur d'API, il vous appartient de déterminer comment ajouter, mettre à jour ou supprimer des développeurs dans votre organisation. Vous pouvez les ajouter manuellement via l'UI, créer un portail des développeurs pour les enregistrer via un site Web ou définir votre propre mécanisme d'enregistrement à l'aide de l'API Apigee. |
Application Apigee (ou application) |
Les développeurs Apigee créent une ou plusieurs applications clientes qui utilisent vos API. Les développeurs créant des applications clientes qui appellent des API nécessitant des vérifications d'identifiants (clés API ou jetons OAuth, par exemple) doivent d'abord créer un enregistrement de l'application auprès de votre organisation. Un enregistrement d'application fournit au développeur la clé API, une paire clé/secret ou d'autres identifiants à utiliser lorsque l'application cliente appelle vos API. Étant donné que toutes les applications sont enregistrées dans votre organisation, vous pouvez utiliser Apigee pour surveiller et collecter des informations analytiques sur l'application et sur l'utilisation de vos API. |
Les composants supplémentaires d'Apigee non affichés dans les clés API et les jetons OAuth.
Apigee est compatible avec différents types d'authentification, tels qu'une clé API simple, l'authentification OAuth à deux acteurs, l'autorisation OAUTH à trois acteurs, etc.
Si le fournisseur d'API spécifie comme mécanisme d'autorisation la validation de clé API, l'application cliente doit transmettre une clé API avec chaque requête adressée à vos API. Si cette clé est valide, Apigee autorise la requête. Sinon, si le fournisseur d'API spécifie comme mécanisme d'autorisation la validation de jeton OAuth, l'application cliente doit d'abord obtenir un jeton OAuth, puis le transmettre à chaque API. Si ce jeton est valide, Apigee autorise la requête. D'autres schémas d'autorisation personnalisés sont possibles.
En tant que fournisseur d'API, vous devez définir une méthode permettant aux développeurs d'enregistrer leurs applications. Chaque enregistrement d'application est associé à un ou plusieurs identifiants ou clés. Si vous autorisez les développeurs à enregistrer leurs propres applications via un portail des développeurs, ils peuvent récupérer la clé ou les identifiants requis pour accéder à vos API via une expérience pratique en libre-service.
Au moment de l'enregistrement de l'application, les développeurs peuvent choisir d'accéder à un seul produit d'API ou à plusieurs. L'application d'un développeur utilise la même clé/le même identifiant pour accéder à tous les produits d'API associés à l'application.
Vous pouvez révoquer la clé à tout moment pour que l'application du développeur n'ait plus accès à vos API (même si la représentation enregistrée pour l'application du développeur existe toujours dans votre organisation). Vous pouvez également définir un délai d'expiration sur une clé, de sorte que le développeur doive l'actualiser après un délai spécifique.
Utilisateurs Apigee
Les utilisateurs Apigee constituent l'équipe API de l'organisation, qui peut inclure des personnes telles que des administrateurs, des créateurs de produits d'API et de proxys d'API, ou encore des utilisateurs surveillant les analyses et d'autres statistiques. Les utilisateurs finaux sont les personnes qui utilisent les applications crées par les développeurs Apigee. Dans la plupart des cas, cette documentation utilise le terme "utilisateur" pour faire référence à un utilisateur Apigee.
Les administrateurs peuvent ajouter des utilisateurs à une organisation.
Les différents utilisateurs peuvent avoir des rôles et droits d'accès spécifiques. Par exemple, définissez certains utilisateurs en tant qu'administrateurs de l'organisation et administrateurs des opérations disposant des droits nécessaires pour modifier l'organisation et ses composants. Définissez d'autres utilisateurs dotés d'autorisations permettant de créer des proxys d'API et des produits d'API, mais qui ne disposent pas des droits nécessaires pour modifier les autres utilisateurs.
Les utilisateurs peuvent être membres de plusieurs organisations. Par exemple, votre entreprise peut définir plusieurs organisations sur Apigee pour prendre en charge différentes communautés de développeurs, même si, en interne, les mêmes personnes créent tous les proxys d'API et tous les produits d'API, et sont donc membres de tous vos organisations.
Vous n'avez pas besoin de créer une organisation Apigee pour être utilisateur. Un administrateur peut vous ajouter à une organisation existante.
Tous les utilisateurs se connectent à Apigee en accédant à l'interface utilisateur d'Apigee.
Droits
Les droits d'accès de l'organisation varient selon que l'organisation payante utilise un modèle de tarification de type Abonnement ou paiement à l'usage.
Droits d'abonnement
Organisations : les droits d'organisation sont exprimés en unités. Lorsque vous obtenez un droit d'unité organisationnelle, vous pouvez l'utiliser pour activer une nouvelle organisation unique dans la région de votre choix ou pour étendre une organisation existante à une nouvelle région unique (en utilisant l'extension de nom de domaine). Pour les droits d'accès, une organisation située dans N régions consomme N unités organisationnelles. Par exemple, si vous achetez quatre nouvelles unités organisationnelles, vous pouvez :
- étendre une organisation existante dans quatre nouvelles régions ;
- ou étendre chacune des deux organisations existantes dans deux nouvelles régions ;
- ou créer quatre organisations, chacune étant disponible dans une région.
Votre nombre total de droits d'unités organisationnelles correspond à l'agrégation de votre niveau d'abonnement et des packs d'organisation pertinents.
Environnements : les droits d'environnement sont également exprimés en unités. Ils sont indépendants des droits d'organisation et se comportent différemment. Pour utiliser un droit d'unité d'environnement, vous devez suivre ce processus en deux étapes : vous devez d'abord créer un environnement, puis vous l'associez à une organisation. Un environnement est comptabilisé dans vos droits d'unité d'environnement lorsqu'il a été associé à une organisation.
L'utilisation des unités d'environnement correspond au nombre d'environnements utilisés sur l'ensemble des organisations et chaque région. En d'autres termes, un environnement provisionné dans deux régions pour une organisation consomme deux unités d'environnement de votre droit.
Votre nombre total de droits d'unités d'environnement correspond au cumul du droit fourni dans votre niveau d'abonnement et des droits supplémentaires obtenus via les packs d'environnement ou d'organisation. L'achat d'un pack d'organisation vous donne une unité organisationnelle et un certain nombre d'unités d'environnement. Les droits d'unités d'environnement ajoutés via un pack d'organisation sont indépendants de toute organisation que vous décidez de créer ou de développer. Les droits d'unités d'environnement ajoutés via des packs d'organisation s'ajoutent simplement à vos droits d'unités d'environnement totaux. Pour ajouter des unités d'environnement sans acheter d'unités d'organisation supplémentaires, vous pouvez acheter un pack d'environnement.
Pour en savoir plus, consultez les droits d'abonnement.
Droits de paiement à l'usage
Organisations : le modèle de paiement à l'usage permet aux titulaires de compte de ne gérer qu'une seule organisation.
Environnements : Les droits d'environnement sont indépendants des droits d'organisation. Ils se comportent également différemment des droits d'organisation, puisqu'il existe un processus en deux étapes pour les utiliser : vous devez d'abord créer un environnement, puis vous l'associez à une organisation. Les environnements ne sont pas comptabilisés dans vos limites de droits tant qu'ils n'ont pas été associés à une organisation.
En d'autres termes, le nombre d'environnements pris en compte dans votre droit correspond au nombre d'environnements associés à une organisation.
Le modèle de paiement à l'usage inclut un droit d'accès à 85 environnements dans toutes les régions.
Pour en savoir plus, consultez les droits de paiement à l'usage.