Cette page s'applique à Apigee et à Apigee hybrid.
Consultez la documentation d'Apigee Edge.
Apigee vous permet d'exposer rapidement des services de backend en tant qu'API. Pour ce faire, vous devez créer un proxy d'API offrant une façade pour le service de backend que vous souhaitez exposer. Fournissez seulement l'adresse réseau du service de backend, ainsi que certaines informations qui permettront à Apigee de créer le proxy d'API qui sera exposé aux développeurs.
Le proxy d'API dissocie l'implémentation de votre service de backend de l'API que les développeurs utilisent. L'objectif est de protéger les développeurs des futurs changements qui seront apportés à vos services de backend. Lorsque vous mettrez à jour vos services de backend, les développeurs, tenus à l'écart de ces changements, pourront continuer à appeler l'API sans interruption.
Cette rubrique fournit des informations sur les différents types de proxys et les paramètres associés. Pour obtenir des instructions détaillées sur la création de proxys, consultez les sections suivantes :
Créer un proxy d'API à l'aide de l'interface utilisateur
Le moyen le plus simple de créer un proxy d'API consiste à utiliser l'assistant de création de proxy.
Pour accéder à l'assistant de création de proxy à l'aide de l'interface utilisateur d'Apigee, procédez comme suit :
- Connectez-vous à l'UI Apigee.
- Dans la barre de navigation, sélectionnez Développer > Proxys d'API.
- Cliquez sur Créer.
L'assistant de création de proxy affiche les différentes étapes à suivre pour générer et ajouter des fonctionnalités minimales à un proxy d'API.
La première page de l'assistant vous permet de créer un proxy d'API à partir des sources suivantes :
Type | Description |
---|---|
Proxy inverse (le plus courant) |
Un proxy d'API qui achemine les requêtes entrantes vers des services de backend HTTP existants. Il peut s'agir d'une API JSON ou XML. Consultez la section Créer un proxy inverse pour un service HTTP plus loin sur cette page. Cliquez sur Use OpenAPI Spec (Utiliser la spécification OpenAPI) pour générer le proxy à partir d'une spécification OpenAPI valide. Pour plus d'informations sur cette option, consultez la section Utiliser des spécifications OpenAPI pour générer des proxys plus loin sur cette page. |
Aucune cible |
Un proxy d'API sans backend de l'API ("aucune cible"). Cette méthode s'apparente à la création d'un proxy inverse pour un service HTTP décrite précédemment, sauf que vous ne devez pas spécifier une API existante lorsque vous définissez les détails du proxy d'API. Cliquez sur Use OpenAPI Spec (Utiliser la spécification OpenAPI) pour générer le proxy à partir d'une spécification OpenAPI valide. Pour plus d'informations sur cette option, consultez la section Utiliser des spécifications OpenAPI pour générer des proxys plus loin sur cette page. |
Importer le groupe de proxys | Un groupe de proxys d'API existant (par exemple, l'un des exemples de proxys d'API disponibles sur GitHub). Voir Importer un proxy d'API à partir d'un groupe de proxys d'API. |
Les sections suivantes détaillent chaque type de proxy.
Créer un proxy inverse pour un service HTTP
Apigee génère des proxys inverses basés sur les informations suivantes :
- URL du service de backend
- Chemin d'URI qui identifie de manière unique l'API qui sera exposée par le proxy d'API aux applications grand public.
L'URL du service de backend représente généralement une application compatible avec le service appartenant à votre organisation. Elle peut également pointer vers une API accessible au public. Il peut s'agir d'une API ou d'un service que vous contrôlez (par exemple, une application RH interne ou une application Rails dans le cloud), ou bien d'une API ou d'un service tiers (par exemple, Twitter ou Instagram).
Les informations sur le proxy suivantes sont disponibles après l'accès à l'assistant de création de proxy et en sélectionnant un type de proxy :
Champ | Description |
---|---|
Nom | Nom affiché pour votre API. Indiquez des caractères alphanumériques, des tirets (-) ou des traits de soulignement (_). |
Chemin de base |
Fragment d'URI qui apparaît après l'adresse Le chemin de base est suivi des URL des éventuelles ressources supplémentaires. Voici la structure d'URL complète que les clients utilisent pour appeler votre proxy d'API :
Utiliser des caractères génériques dans les chemins de base Utilisez un ou plusieurs caractères génériques |
Description | (Facultatif) Description de l'API. |
Cible (API existante) | URL du service de backend que ce proxy d'API appelle. |
Importer un proxy d'API à partir d'un package de proxy d'API
Les proxys d'API sont souvent définis comme des ensembles de fichiers XML accompagnés d'autres fichiers sources. En définissant vos proxys d'API en tant qu'ensemble de fichiers extérieurs à Apigee, vous pouvez les conserver dans un système de gestion de code source, puis les importer dans Apigee à des fins de test et de déploiement.
Pour importer des proxys d'API à partir d'un groupe de proxys d'API, procédez comme suit :
- Accédez à l'assistant de création de proxy, comme décrit dans la section Créer un proxy d'API à l'aide de l'interface utilisateur plus haut sur cette page.
- Cliquez sur Importer le groupe de proxys.
-
Sur la page Importer le groupe de proxys de l'assistant de proxy, saisissez les informations suivantes :
Champ Description Dossier ZIP Fichier ZIP contenant la configuration du proxy d'API. Accédez au fichier par glisser-déposer ou en effectuant un clic. Nom Nom affiché pour votre API. Correspond par défaut au nom du fichier ZIP sans l'extension. - Cliquez sur Suivant.
Sur la page Summary (Résumé), sélectionnez les environnements de déploiement, si vous le souhaitez, puis cliquez sur Create and deploy (Créer et déployer).
Un accusé de réception s'affiche pour confirmer que votre nouveau proxy d'API a bien été créé.
- Cliquez sur Modifier le proxy pour afficher la page d'informations du proxy d'API.
Créer des proxys d'API gRPC
En plus des proxys d'API REST, Apigee est actuellement compatible avec les proxys d'API gRPC, pour le moment exclusivement en passthrough. Avec compatibilité passthrough, la charge utile gRPC est opaque au niveau d'Apigee et le trafic est acheminé depuis le client gRPC vers le serveur cible gRPC préconfiguré dans la configuration cible.À ce stade, les proxys d'API gRPC Apigee :
- acceptent les requêtes gRPC unaires ;
- ne peuvent pas utiliser de règles qui affectent la charge utile ;
- peuvent être utilisés dans les produits d'API qui ne sont pas associés à des proxys GraphQL ou REST. Les quotas spécifiques aux produits d'API et les autres paramètres d'opération s'appliquent à tous les proxys du produit ;
- ne sont pas compatibles avec Apigee hybrid ;
- utilisent deux variables de flux spécifiques à gRPC :
request.grpc.rpc.name
etrequest.grpc.service.name
; -
peuvent être surveillés avec ces variables Apigee Analytics spécifiques à gRPC :
x_apigee_grpc_rpc_name
,x_apigee_grpc_service_name
etx_apigee_grpc_status
; - renvoient des codes d'état gRPC.
Vous devez également configurer votre équilibreur de charge pour qu'il soit compatible avec gRPC. Consultez les pages Utiliser gRPC avec vos applications et Créer un routage pour gRPC à l'aide des commandes gcloud CLI.
Pour créer un proxy d'API gRPC, définissez d'abord un serveur cible gRPC (consultez la section Créer des TargetServers), puis spécifiez ce serveur cible lors de la création du proxy.
Créer un routage pour gRPC à l'aide des commandes gcloud CLI
Cette section présente des exemples de commandes permettant de créer un routage pour des proxys gRPC à l'aide de gcloud CLI. Ces instructions incluent la configuration des équilibreurs de charge, d'un serveur cible et d'un MIG.
Cette section n'est pas un guide complet de création du routage. Ces exemples peuvent ne pas convenir à tous les cas d'utilisation. En outre, ces instructions supposent que vous maîtrisez le routage externe (MIG) et la configuration gRPC des équilibreurs de charge cloud.
Définir des variables d'environnement
Les variables d'environnement suivantes sont utilisées dans les commandes figurant dans les sous-sections.
PROJECT_ID=YOUR_PROJECT_ID MIG_NAME=YOUR_MIG_NAME VPC_NAME=default VPC_SUBNET=default REGION=REGION_NAME APIGEE_ENDPOINT=ENDPOINT CERTIFICATE_NAME=CERTIFICATE_NAME DOMAIN_HOSTNAME=DOMAIN_HOSTNAME
Exemples de commandes gcloud CLI permettant de créer un routage pour des proxys gRPC, dans le cas de nouveaux équilibreurs de charge
Cette section présente des exemples de commandes permettant de créer des proxys gRPC à l'aide de gcloud CLI et d'un nouvel équilibreur de charge. Ces instructions incluent la configuration de l'équilibreur de charge, d'un serveur cible et d'un MIG.
Créer le modèle d'instance
gcloud compute instance-templates create $MIG_NAME \ --project $PROJECT_ID \ --region $REGION \ --network $VPC_NAME \ --subnet $VPC_SUBNET \ --tags=https-server,apigee-mig-proxy,gke-apigee-proxy \ --machine-type e2-medium --image-family debian-12 \ --image-project debian-cloud --boot-disk-size 20GB \ --no-address \ --metadata ENDPOINT=$APIGEE_ENDPOINT,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh
Créer le groupe d'instances géré
gcloud compute instance-groups managed create $MIG_NAME \ --project $PROJECT_ID --base-instance-name apigee-mig \ --size 2 --template $MIG_NAME --region $REGION
Configurer l'autoscaling
gcloud compute instance-groups managed set-autoscaling $MIG_NAME \ --project $PROJECT_ID --region $REGION --max-num-replicas 50 \ --target-cpu-utilization 0.75 --cool-down-period 90
Définir un port nommé
gcloud compute instance-groups managed set-named-ports $MIG_NAME \ --project $PROJECT_ID --region $REGION --named-ports https:443
Créer un certificat SSL et une clé gérés par Google pour l'équilibreur de charge
gcloud compute ssl-certificates create $CERTIFICATE_NAME \ --domains=$DOMAIN_HOSTNAME \ --project $PROJECT_ID \ --global
Vérifier que le certificat a été provisionné
gcloud compute ssl-certificates describe $CERTIFICATE_NAME \ --global \ --format="get(name,managed.status, managed.Status)"
Créer l'équilibreur de charge cloud mondial (GCLB)
- Créez une vérification d'état
gcloud compute health-checks create https hc-apigee-envoy-443 \ --project $PROJECT_ID --port 443 --global \ --request-path /healthz/ingress
- Créez le service de backend pour http1
gcloud compute backend-services create
YOUR_BACKEND_1 \ --project $PROJECT_ID \ --protocol HTTPS \ --health-checks hc-apigee-envoy-443 \ --port-name https \ --timeout 302s \ --connection-draining-timeout 300s \ --global - Créez le service de backend pour http2
gcloud compute backend-services create
YOUR_BACKEND_2 \ --project $PROJECT_ID \ --protocol HTTP2 \ --health-checks hc-apigee-envoy-443 \ --port-name https \ --timeout 302s \ --connection-draining-timeout 300s \ --global - Ajoutez des MIG au service de backend. Dans cet exemple, nous réutilisons le MIG existant, mais vous pouvez également créer une nouvelle paire de MIG.
gcloud compute backend-services add-backend
YOUR_BACKEND_1 \ --project $PROJECT_ID --instance-group $MIG_NAME \ --instance-group-region $REGION \ --balancing-mode UTILIZATION --max-utilization 0.8 --globalgcloud compute backend-services add-backend
YOUR_BACKEND_2 \ --project $PROJECT_ID --instance-group $MIG_NAME \ --instance-group-region $REGION \ --balancing-mode UTILIZATION --max-utilization 0.8 --global - Créez un mappage d'URL d'équilibrage de charge. Vérifiez d'abord si vous disposez déjà d'un mappage d'URL. Si oui, veillez à modifier ce mappage en fonction des exigences ci-dessous plutôt que de l'écraser.
Créez un fichier YAML ou utilisez votre fichier existant, situé dans
/tmp/apigee-map.yaml
, avec cette configuration. Notez que le backend http1 du mappage d'URL est utilisé par défaut.defaultService: projects/$PROJECT_ID/global/backendServices/
YOUR_BACKEND_1 name: matcher1 routeRules: - matchRules: - headerMatches: - headerName: Content-Type prefixMatch: application/grpc prefixMatch: / priority: 100 routeAction: weightedBackendServices: - backendService: projects/$PROJECT_ID/global/backendServices/YOUR_BACKEND_2 weight: 100Validez le mappage d'URL :
gcloud compute url-maps validate --source /tmp/apigee-map.yaml --project $PROJECT_ID
Créez le mappage d'URL avec un routage basé sur les en-têtes :
gcloud compute url-maps import apigee-http1-http2 \ --source /tmp/apigee-map.yaml \ --global --project $PROJECT_ID
Créer un proxy HTTPS cible d'équilibrage de charge
gcloud compute target-https-proxies create apigee-envoy-https-proxy \ --project $PROJECT_ID --url-map apigee-envoy-proxy-map \ --ssl-certificates $CERTIFICATE_NAME
Réserver une adresse IP externe IPV4 et créer des règles de pare-feu pour l'équilibreur de charge
gcloud compute addresses create lb-ipv4-vip-1 \ --project $PROJECT_ID \ --network-tier=PREMIUM \ --ip-version=IPV4 \ --global gcloud compute addresses describe lb-ipv4-vip-1 \ --project $PROJECT_ID --format="get(address)" --global gcloud compute forwarding-rules create apigee-envoy-https-lb-rule \ --project $PROJECT_ID --address lb-ipv4-vip-1 --global \ --target-https-proxy apigee-envoy-https-proxy --ports 443
Créer une règle de pare-feu
gcloud compute firewall-rules create k8s-allow-lb-to-apigee-envoy \ --description "Allow incoming from GLB on TCP port 443 to Apigee Proxy" \ --project $PROJECT_ID --network $VPC_NAME --allow=tcp:443 \ --source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gke-apigee-proxy
Exemples de commandes gcloud CLI permettant de créer un routage pour des proxys gRPC, dans le cas d'équilibreurs de charge existants
Cette section présente des exemples de commandes permettant de créer des proxys gRPC à l'aide de gcloud CLI et d'un équilibreur de charge existant. Ces instructions incluent la configuration de l'équilibreur de charge, d'un serveur cible et d'un MIG.
Créer un autre service de backend pour http2
# Create backend service for http2 gcloud compute backend-services createYOUR_BACKEND_2 \ --project $PROJECT_ID \ --protocol HTTP2 \ --health-checks hc-apigee-envoy-443 \ --port-name https \ --timeout 302s \ --connection-draining-timeout 300s \ --global
Associer le deuxième service de backend au MIG
gcloud compute backend-services add-backendYOUR_BACKEND_2 \ --project $PROJECT_ID --instance-group $MIG_NAME \ --instance-group-region $REGION \ --balancing-mode UTILIZATION --max-utilization 0.8 --global
Lister le mappage d'URL pour l'équilibreur de charge GCLB Apigee existant
gcloud compute url-maps list -project $PROJECT_ID
Récupérer le nom du mappage d'URL approprié, utilisé pour l'équilibrage de charge Apigee
gcloud compute url-maps exportAPIGEE_URL_MAP_NAME -project $PROJECT_ID
Créer un fichier YAML de mappage d'URL d'équilibrage de charge
Si vous disposez déjà d'un mappage d'URL, fusionnez cette configuration avec celui-ci. Sinon, créez un fichier YAML dans /tmp/apigee-map.yaml
avec cette configuration.
defaultService: projects/dg-runtime-test1/global/backendServices/YOUR_BACKEND_1 name: matcher1 routeRules: - matchRules: - headerMatches: - headerName: Content-Type prefixMatch: application/grpc prefixMatch: / priority: 100 routeAction: weightedBackendServices: - backendService: projects/dg-runtime-test1/global/backendServices/YOUR_BACKEND_2 weight: 100
Appliquer le nouveau fichier YAML pour le routage gRPC
gcloud compute url-maps importAPIGEE_URL_MAP_NAME \ --source /tmp/apigee-map.yaml \ --global -project $PROJECT_ID
Ajout de sécurité
Sur la page Règles communes de l'assistant de création de proxy, sélectionnez le type d'autorisation de sécurité que vous souhaitez ajouter. Le tableau suivant récapitule les options disponibles :
Autorisation de sécurité | Description |
---|---|
Clé API | Ajoute une validation de clé API simple au proxy d'API que vous définissez. En réponse, la plate-forme d'API ajoute une règle VerifyAPIKey et une règle AssignMessage à votre proxy d'API. La règle VerifyAPIKey valide les clés API présentées par les applications demandeuses. La règle AssignMessage supprime la clé API, fournie dans l'appel d'API en tant que paramètre de requête, de la requête transmise au serveur backend. |
OAuth 2.0 | Ajoute l'authentification basée sur OAuth 2.0 à votre proxy d'API. Apigee ajoute automatiquement les règles suivantes à votre proxy d'API : une règle pour vérifier un jeton d'accès et une autre pour supprimer le jeton d'accès du message avant qu'il ne soit transféré à votre service de backend. Pour savoir comment obtenir un jeton d'accès, consultez la page OAuth. |
Directe (sans autorisation) | Aucune autorisation requise. Les requêtes sont transmises au backend sans contrôle de sécurité sur Apigee. |
Assurer la compatibilité avec CORS
Le partage de ressources entre origines multiples (CORS, Cross-Origin Resource Sharing) est un mécanisme standard qui permet à un navigateur Web d'envoyer des requêtes directes à un autre domaine. Cette norme définit un ensemble d'en-têtes HTTP que les navigateurs Web et les serveurs utilisent pour mettre en œuvre la communication entre domaines.
Vous pouvez ajouter la compatibilité avec le CORS en effectuant l'une des actions suivantes :
- Ajouter la règle CORS au PreFlow de requête du ProxyEndpoint
- Sélectionner Ajouter des en-têtes CORS sur la page Règles communes de l'assistant Créer un proxy.
Pour plus d'informations sur la compatibilité CORS, y compris l'ajout de la compatibilité CORS préliminaire à un proxy, consultez la page Ajouter la compatibilité CORS à un proxy d'API.
Ajouter des quotas
Les quotas protègent votre service de backend contre le trafic élevé sous Quota. Consultez la section Quotas. (Non disponible si l'autorisation directe est sélectionnée).
Utiliser des spécifications OpenAPI pour générer des proxys
Cette section traite de l'option Utiliser le protocole OpenAPI qui est permet de générer des types de serveurs proxy d'API "inversés" ou "no target" à partir d'une spécification OpenAPI.
Qu'est-ce qu'une spécification OpenAPI ?
L'OpenAPI Initiative (OAI) se concentre sur la création, l'évolution et la promotion d'un format de description d'API neutre du point de vue du fournisseur, basé sur la spécification Swagger." Pour en savoir plus, consultez la page OpenAPI Initiative.
Une spécification OpenAPI utilise un format standard pour décrire une API RESTful. Développées au format JSON ou YAML, les spécifications OpenAPI sont lisibles par une machine, mais sont également faciles à lire et à comprendre. La spécification décrit les éléments d'une API, tels que son chemin de base, ses chemins et verbes, en-têtes, paramètres de requête, opérations, types de contenu, descriptions de réponse, etc. En outre, une spécification OpenAPI est couramment utilisée pour générer la documentation de l'API.
Le fragment suivant d'une spécification OpenAPI décrit le service cible fictif d'Apigee, http://mocktarget.apigee.net. Pour en savoir plus, consultez la page Spécification OpenAPI pour l'exemple helloworld.
openapi: 3.0.0 info: description: OpenAPI Specification for the Apigee mock target service endpoint. version: 1.0.0 title: Mock Target API paths: /: get: summary: View personalized greeting operationId: View a personalized greeting description: View a personalized greeting for the specified or guest user. parameters: - name: user in: query description: Your user name. required: false schema: type: string responses: "200": description: Success /help: get: summary: Get help operationId: Get help description: View help information about available resources in HTML format. responses: "200": description: Success ...
Avec l'assistant de création de proxy, vous pouvez importer une spécification OpenAPI et l'utiliser pour générer un proxy d'API. Une fois le proxy généré, vous pouvez utiliser l'interface utilisateur d'Apigee pour le développer davantage en ajoutant des règles, en mettant en œuvre du code personnalisé, et plus encore, comme vous pourriez le faire sur n'importe quel proxy Apigee.
Créer un proxy d'API à partir d'une spécification OpenAPI
Créez vos proxys d'API à partir d'une spécification OpenAPI. En quelques clics, vous obtenez un proxy d'API avec les chemins, paramètres, flux conditionnels et points de terminaison cibles générés automatiquement. Vous pouvez ensuite ajouter des fonctionnalités telles que la sécurité OAuth, la limitation du débit et la mise en cache.
Dans l'assistant de création de proxy, cliquez sur Use OpenAPI Spec (Utiliser la spécification OpenAPI) et suivez l'assistant pour créer un proxy inverse ou sans cible à partir d'une spécification OpenAPI. Pour plus d'informations, consultez la page Créer un proxy d'API à partir d'une spécification OpenAPI.
Créer une révision d'un proxy d'API
Créez une révision d'un proxy d'API, comme décrit ci-dessous.
Pour créer une révision d'un proxy d'API, procédez comme suit :
- Connectez-vous à l'UI Apigee.
- Dans la barre de navigation, sélectionnez Développer > Proxys d'API.
- Dans la liste, cliquez sur le proxy d'API que vous souhaitez copier.
-
Cliquez sur l'onglet Développer :
- Cliquez sur le bouton Enregistrer, puis sur Enregistrer en tant que nouvelle révision.
Sauvegarder un proxy d'API
Vous pouvez sauvegarder un proxy d'API existant sous la forme d'un ensemble de fichiers XML dans un groupe de proxys d'API. Une fois le proxy d'API exporté vers un groupe, vous pouvez l'importer dans un nouveau proxy, comme décrit dans la section Importer un proxy d'API à partir d'un groupe de proxys d'API plus haut sur cette page. Pour plus d'informations, consultez la page Télécharger des proxys d'API.
Créer un proxy d'API à l'aide de l'API
Pour créer un proxy d'API à l'aide de l'API, consultez la page Créer un proxy d'API.