Creazione di un proxy API semplice

Questa pagina si applica a Apigee e Apigee ibridi.

Visualizza documentazione di Apigee Edge.

Nota: negli ambienti abilitati per i deployment degli archivi, non puoi creare proxy API utilizzando la UI o l'API Apigee o gcloud. Per creare proxy API per i deployment di archiviazione utilizzando Apigee in VS Code,consulta Sviluppare proxy API utilizzando Apigee in VS Code.

Apigee consente di esporre rapidamente i servizi di backend come API. Per farlo, devi creare Proxy API che fornisce un'interfaccia per il servizio di backend che vuoi esporre. Ti servono di fornire solo l'indirizzo di rete per il servizio di backend, insieme ad alcune informazioni Apigee utilizza per creare il proxy API esposto agli sviluppatori.

Il proxy API disaccoppia l'implementazione del servizio di backend dall'API che gli sviluppatori consumare. Questo protegge gli sviluppatori da future modifiche ai tuoi servizi di backend. Durante l'aggiornamento di backend, gli sviluppatori, isolati da queste modifiche, possono continuare a chiamare l'API senza interruzioni.

In questo argomento vengono fornite informazioni sui vari tipi di proxy e sulle relative impostazioni. Per istruzioni dettagliate sulla creazione dei proxy, consulta i seguenti argomenti:

• Tutorial: Crea il tuo primo proxy API
• Creazione di un proxy API

Nota: il seguente video mostra la versione classica dell'Editor proxy nello UI di Apigee. Apigee sta introducendo una nuova versione del proxy Editor, che ha un design diverso dalla versione classica mostrata nel video.

Creazione di un proxy API mediante l'interfaccia utente

Il modo più semplice per creare un proxy API è utilizzare la procedura guidata Crea proxy.

Per accedere alla procedura guidata Crea proxy utilizzando la UI di Apigee, segui questi passaggi:

1. Accedi all'UI di Apigee.
2. Nella barra di navigazione, seleziona Sviluppo > Proxy API.
3. Fai clic su Crea nuovo.
   

La procedura guidata Crea proxy viene visualizzata e illustra i passaggi per generare e aggiungere funzionalità minime a un proxy API.

La prima pagina della procedura guidata consente di creare un proxy API dalle origini seguenti:

Tipo	Descrizione
Proxy inverso (più comune)	Un proxy API che instrada le richieste in entrata ai servizi di backend HTTP esistenti. Può essere un'API JSON o XML. Consulta la sezione Creare un'inversione proxy per un servizio HTTP più avanti in questa sezione. Fai clic su Utilizza specifica OpenAPI per generare il proxy da una specifica OpenAPI valida. Specifica. Per ulteriori informazioni su questa opzione, consulta la sezione Utilizzo di OpenAPI Specifiche per la generazione dei proxy più avanti in questa sezione.
Nessun target	Un proxy API senza backend API ("nessun target"). Simile a Creazione di un proxy inverso per una richiesta HTTP servizio descritto in precedenza, con la differenza che non specificherai un'API esistente quando che definisce i dettagli del proxy API. Fai clic su Utilizza specifica OpenAPI per generare il proxy da una specifica OpenAPI valida. la specifica del container. Per ulteriori informazioni su questa opzione, consulta la sezione Utilizzo di OpenAPI Specifiche per la generazione dei proxy più avanti in questa sezione.
Carica bundle proxy	Un bundle proxy API esistente (ad esempio uno dei proxy API di esempio disponibile su GitHub). Vedi Importazione di un proxy API da un bundle proxy API.

Le sezioni seguenti discutono i dettagli di ciascun tipo di proxy.

Creazione di un proxy inverso per un servizio HTTP

Apigee genera proxy inversi in base alle seguenti informazioni:

• URL del servizio di backend.
• Percorso URI che identifica in modo univoco l'API che sarà esposta dal proxy API a le app consumer.

L'URL del servizio di backend in genere rappresenta un'applicazione abilitata per il servizio di proprietà del dell'organizzazione. Può anche puntare a un'API disponibile pubblicamente. L'API o il servizio possono essere (ad esempio, un'applicazione RU interna o un'applicazione Rails nel cloud) Essere un'API o un servizio di terze parti (ad esempio Twitter o Instagram).

I seguenti Dettagli del proxy sono disponibili dopo aver eseguito l'accesso alla procedura guidata di creazione proxy e selezionando un tipo di proxy:

Campo	Descrizione
Nome	Nome visualizzato per l'API. Specifica caratteri alfanumerici, il trattino (-) o il trattino basso (_).
Percorso di base	Frammento di URI visualizzato dopo l'indirizzo http://[host] o https://[host] del tuo proxy API. Apigee utilizza l'URI del percorso di base per trovare corrispondenze e instradare i messaggi delle richieste in arrivo al proxy API corretto. Nota: per impostazione predefinita, il percorso di base del proxy API è impostato sul valore specificato per il campo Name convertito in lettere minuscole. Seguendo il percorso di base sono presenti eventuali URL di risorsa aggiuntivi. L'URL completo utilizzata dai client per chiamare il proxy API è la seguente: https://[host]/BASE_PATH/CONDITIONAL_FLOW_PATH Nota: il percorso di base deve essere univoco. non puoi eseguire il deployment di due proxy API del percorso di base. Se modifichi un proxy API di cui è stato eseguito il deployment e impostare il percorso di base sullo stesso valore di quello di un altro proxy API, Apigee annulla il deployment il proxy API quando lo salvi. Prima di poter eseguire nuovamente il deployment del proxy API, devi modificare il percorso di base in modo che sia univoco. Utilizzare caratteri jolly nei percorsi di base Utilizza uno o più caratteri jolly /*/ nei percorsi di base dei proxy API per a prova di futuro. Ad esempio, un percorso di base /team/*/members consente ai clienti di chiamare https://[host]/team/blue/members e https://[host]/team/green/members senza di te di creare nuovi proxy API per supportare nuovi team. Tieni presente che /**/ non è supportati.
Descrizione	(Facoltativo) Descrizione dell'API.
Target (API esistente)	URL del servizio di backend chiamato da questo proxy API.

Importazione di un proxy API da un bundle proxy API

Nota: quando importi un proxy API da un bundle proxy API, responsabile configurando la sicurezza e aggiungendo criteri al bundle. L'interfaccia utente non richiede di aggiungere alla sicurezza o alle norme durante l'importazione come descritto in Aggiungere sicurezza più avanti in questa sezione.

Spesso definisci i proxy API come una raccolta di file XML, insieme a qualsiasi altro file di supporto. Se definisci i proxy API come un insieme di file esterni ad Apigee, puoi mantenerle in un sistema di controllo del codice sorgente e quindi importarle in Apigee per testarle e deployment continuo.

Per importare i proxy API da un bundle proxy API, segui questi passaggi:

1. Accedi alla procedura guidata Crea proxy come descritto in Creazione di un proxy API utilizzando l'interfaccia utente in precedenza in questa sezione.
2. Fai clic su Carica bundle proxy.

3. Nella pagina Carica bundle proxy nella procedura guidata del proxy, inserisci quanto segue. informazioni:

   Campo	Descrizione
   Bundle ZIP	ZIP contenente la configurazione del proxy API. Trascina o fai clic per accedere al file.
   Nome	Nome visualizzato per l'API. Il valore predefinito è il nome del file ZIP senza estensione.

4. Fai clic su Avanti.

5. Nella pagina Riepilogo, seleziona gli ambienti di deployment, se necessario, e fai clic su Crea ed esegui il deployment

   Viene visualizzato un messaggio di conferma che conferma che il nuovo proxy API è stato creato correttamente.

6. Fai clic su Modifica proxy per visualizzare la pagina dei dettagli del proxy API.

Creazione di proxy API gRPC

Oltre ai proxy API REST, Apigee supporta i proxy API gRPC con passthrough al momento. Con il supporto passthrough, il payload gRPC è di per sé opaco ad Apigee e il traffico viene instradato dal client gRPC alla piattaforma gRPC preconfigurata server di destinazione nella configurazione di destinazione.

Al momento, i proxy dell'API Apigee gRPC:

• Supporta le richieste gRPC unari.
• Impossibile utilizzare criteri che influiscono sul payload.
• Può essere utilizzato in prodotti API non associati a GraphQL o ai proxy REST. API quote specifiche del prodotto e altre impostazioni operative si applicano a tutti i proxy nel prodotto.
• Non sono supportate in Apigee hybrid.
• Utilizza due variabili di flusso specifiche per gRPC: request.grpc.rpc.name e request.grpc.service.name.
• Possono essere monitorate con queste variabili di analisi Apigee specifiche per gRPC: x_apigee_grpc_rpc_name, x_apigee_grpc_service_name e x_apigee_grpc_status.
• Restituisci i codici di stato gRPC.

Devi anche configurare il bilanciatore del carico per supportare gRPC. Consulta Utilizzo di gRPC con le applicazioni e Utilizzare i comandi della gcloud CLI per creare il routing per gRPC.

Per creare un proxy API gRPC, per prima cosa definisci un server di destinazione gRPC (vedi Creazione di TargetServer) e specificare il server di destinazione quando crei il nuovo proxy.

Nota: la configurazione del proxy gRPC tramite la UI di Apigee è supportata tramite la Solo UI di Apigee nella console Cloud, al limite di altre console Apigee.

Utilizzo dei comandi gcloud CLI per creare il routing per gRPC

Questa sezione mostra comandi di esempio per la creazione di routing per i proxy gRPC, utilizzando gcloud CLI. Le istruzioni includono la configurazione bilanciatori del carico, un server di destinazione e un gruppo di istanze gestite.

Questa sezione non è una guida esaustiva per la creazione dei percorsi. Questi esempi potrebbero non essere appropriati per tutti i casi d'uso. Inoltre, queste istruzioni presuppongono familiarità con Routing esterno (MIG) e la configurazione gRPC del bilanciatore del carico Cloud.

Impostare le variabili di ambiente

Queste variabili di ambiente vengono utilizzate nei comandi delle sottosezioni.

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

Esempi di comandi gcloud CLI per creare il routing per i proxy gRPC utilizzando i nuovi bilanciatori del carico

Questa sezione mostra comandi di esempio per la creazione di proxy gRPC utilizzando gcloud CLI e un nuovo bilanciatore del carico. La le istruzioni includono la configurazione del bilanciatore del carico, di un server di destinazione e di un gruppo di istanze gestite.

Crea il modello di istanza

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

Crea il gruppo di istanze gestite

gcloud compute instance-groups managed create $MIG_NAME \
--project $PROJECT_ID --base-instance-name apigee-mig \
--size 2 --template $MIG_NAME --region $REGION

Configura la scalabilità automatica

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

Definire una porta denominata

gcloud compute instance-groups managed set-named-ports $MIG_NAME \
--project $PROJECT_ID --region $REGION --named-ports https:443

Crea un certificato SSL e una chiave gestiti da Google per il bilanciatore del carico

gcloud compute ssl-certificates create $CERTIFICATE_NAME \
--domains=$DOMAIN_HOSTNAME \
--project $PROJECT_ID \
--global

Verificare che sia stato eseguito il provisioning del certificato

gcloud compute ssl-certificates describe $CERTIFICATE_NAME \
--global \
--format="get(name,managed.status, managed.Status)"

Crea il bilanciatore del carico Cloud globale (GCLB)

1. Crea un controllo di integrità
   

   gcloud compute health-checks create https hc-apigee-envoy-443 \
   --project $PROJECT_ID --port 443 --global \
   --request-path /healthz/ingress

2. Crea il servizio di backend per 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

3. Crea il servizio di backend per 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

4. Aggiungere gruppi di istanze gestite al servizio di backend. In questo esempio riutilizziamo il gruppo di istanze gestite, ma potresti anche creare una nuova coppia di gruppi di istanze gestite.
   

   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 --global

   gcloud 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

5. Crea una mappa URL di bilanciamento del carico. Verifica innanzitutto se disponi già di una mappa URL. Se assicurati di modificare la mappa in base ai requisiti riportati di seguito, anziché sovrascriverla.
   

   Crea un file YAML o utilizza il tuo file esistente, su /tmp/apigee-map.yaml, con questo configurazione. Tieni presente che il backend http1 della mappa URL è predefinito.

   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: 100

   Convalida la mappa URL:

   gcloud compute url-maps validate --source /tmp/apigee-map.yaml --project $PROJECT_ID

   Crea la mappa URL con il routing basato su intestazioni:

   gcloud compute url-maps import apigee-http1-http2 \
   --source /tmp/apigee-map.yaml  \
   --global --project $PROJECT_ID

Crea un proxy HTTPS di destinazione del bilanciamento del carico

gcloud compute target-https-proxies create apigee-envoy-https-proxy \
--project $PROJECT_ID --url-map apigee-envoy-proxy-map \
--ssl-certificates $CERTIFICATE_NAME

Prenota un IP esterno IPV4 e crea regole firewall per il bilanciatore del carico

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

Crea una regola firewall

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

Esempi di comandi gcloud CLI per creare il routing per i proxy gRPC per i bilanciatori del carico esistenti

Questa sezione mostra comandi di esempio per la creazione di proxy gRPC utilizzando gcloud CLI e un bilanciatore del carico esistente. La le istruzioni includono la configurazione del bilanciatore del carico, di un server di destinazione e di un gruppo di istanze gestite.

Crea un altro servizio di backend per http2

# Create backend service for 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

Collega il secondo servizio di backend al gruppo di istanze gestite

gcloud 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

Elenca la mappa URL per il GCLB Apigee esistente

gcloud compute url-maps list -project $PROJECT_ID

Scegliere il nome corretto della mappa URL utilizzato per il bilanciamento del carico di Apigee

gcloud compute url-maps export APIGEE_URL_MAP_NAME -project $PROJECT_ID

Crea un file YAML della mappa di URL del bilanciamento del carico

Se hai già una mappa URL, unisci questa configurazione alla mappa. Altrimenti, crea un file YAML file in /tmp/apigee-map.yaml con questa configurazione.

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

Applica il nuovo YAML per il routing gRPC

gcloud compute url-maps import APIGEE_URL_MAP_NAME\
--source /tmp/apigee-map.yaml  \
--global -project $PROJECT_ID

Maggiore sicurezza

Nella pagina Criteri comuni della procedura guidata Crea proxy, seleziona il tipo dell'autorizzazione di sicurezza che vuoi aggiungere. La seguente tabella riassume le opzioni disponibili:

Autorizzazione di sicurezza	Descrizione
Chiave API	Aggiunge una semplice verifica della chiave API al proxy API che stai che definiremo. In risposta, la piattaforma API aggiunge un criterio VerifyAPIKey e un criterioAssignMessage al proxy API. Il criterio VerifyAPIKey convalida le chiavi API presentate dalle richieste di app. La Il criterioAssignMessage rimuove la chiave API, fornita nella chiamata API come parametro di query, da la richiesta inoltrata al server di backend.
OAuth 2.0	Aggiunge l'autenticazione basata su OAuth 2.0 al proxy API. Apigee aggiunge automaticamente i seguenti criteri al proxy API: un criterio per verificare un token di accesso e un altro per rimuovere il token di accesso dal messaggio prima di inoltrarlo al backend completamente gestito di Google Cloud. Per informazioni su come ottenere un token di accesso, consulta OAuth.
Passthrough (nessuna autorizzazione)	Nessuna autorizzazione richiesta. Le richieste vengono passate al backend senza alcuna sicurezza su Apigee.

Aggiunta del supporto per CORS

La condivisione delle risorse tra origini (CORS) è un meccanismo standard che consente a un browser web di le richieste dirette a un altro dominio. Lo standard CORS definisce un insieme di intestazioni HTTP che i browser e i server utilizzati per implementare le comunicazioni tra domini.

Puoi aggiungere il supporto per CORS effettuando una delle seguenti operazioni:

• Aggiunta del criterio CORS alla richiesta PreFlow del ProxyEndpoint
• Selezionando Aggiungi intestazioni CORS nella pagina Criteri comuni della Procedura guidata Crea proxy

Per informazioni più dettagliate sul supporto CORS, inclusa l'aggiunta del supporto preflight CORS a un proxy, consulta la sezione sull'aggiunta di CORS a un proxy API.

Aggiunta di quote

Le quote proteggono il servizio di backend dal traffico elevato in base alla quota. Vedi Quote. (non disponibile se è selezionata l'autorizzazione passthrough).

Utilizzo delle specifiche OpenAPI per generare proxy

Questa sezione illustra l'opzione Usa OpenAPI disponibile per la generazione da un'API OpenAPI Specifica i seguenti tipi di proxy API: inversione o nessun target.

Che cos'è un Specifica OpenAPI?

"L'iniziativa Open API Initiative (OAI) è incentrata sulla creazione, sull'evoluzione e sulla promozione di un ambiente indipendente dal fornitore Formato della descrizione dell'API basato sulla specifica Swagger." Per ulteriori informazioni, vedi Iniziativa OpenAPI.

Una specifica OpenAPI utilizza un formato standard per descrivere un'API RESTful. Scritta in formato JSON o YAML, una specifica OpenAPI è leggibile dalle macchine, ma è anche di facile lettura e comprensione per gli esseri umani. La specifica descrive elementi dell'API come relativo percorso di base, percorsi e verbi, intestazioni, parametri di ricerca, operazioni, tipi di contenuti, risposta descrizioni e altro. Inoltre, una specifica OpenAPI viene comunemente utilizzata per generare documentazione.

Il seguente frammento di una specifica OpenAPI descrive il servizio di destinazione fittizio di Apigee, http://mocktarget.apigee.net. Per Per ulteriori informazioni, vedi le specifiche OpenAPI per l'esempio 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
...

Con la procedura guidata Crea proxy, puoi importare una specifica OpenAPI e utilizzarla per generare un proxy API. Una volta generato il proxy, puoi utilizzare la UI di Apigee per svilupparlo ulteriormente aggiungendo criteri, implementando codice personalizzato e così via, proprio come qualsiasi altra Apigee proxy.

Creazione di un proxy API da una specifica OpenAPI

Crea i proxy API da una specifica OpenAPI. Con pochi clic, disponi di un'API proxy con percorsi, parametri, flussi condizionali ed endpoint di destinazione generati automaticamente. Successivamente, puoi aggiungere funzionalità come la sicurezza OAuth, la limitazione di frequenza e la memorizzazione nella cache.

Nella procedura guidata Crea proxy, fai clic su Utilizza specifica OpenAPI e segui la procedura guidata per creare un proxy inverso o nessun proxy di destinazione da una specifica OpenAPI. Per maggiori dettagli, vedi Creazione di un proxy API da una specifica OpenAPI.

Creazione di una nuova revisione di un proxy API

Crea una nuova revisione di un proxy API, come descritto di seguito.

Per creare una nuova revisione di un proxy API, segui questi passaggi:

1. Accedi all'UI di Apigee.
2. Nella barra di navigazione, seleziona Sviluppo > Proxy API.
3. Fai clic sul proxy API nell'elenco da copiare.

4. Fai clic sulla scheda Sviluppo.

5. Seleziona il pulsante Salva e seleziona Salva come nuova revisione.

Backup di un proxy API

Puoi eseguire il backup di un proxy API esistente come set di file XML in un bundle di proxy API. Una volta esportato in un bundle, puoi importare il proxy API in un nuovo proxy, come descritto in Importazione di un proxy API da un bundle proxy API in precedenza in questa sezione. Per ulteriori informazioni, vedi Scarica i proxy API.

Creazione di un proxy API mediante l'API

Per creare un proxy API utilizzando l'API, consulta Creazione di un proxy API.