Creazione di un proxy API semplice

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

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

Apigee ti consente di esporre rapidamente i servizi di backend come API. A questo scopo, crea un proxy API che fornisca una facade per il servizio di backend che vuoi esporre. Devi fornire solo l'indirizzo di rete per il servizio di backend, insieme ad alcune informazioni che Apigee utilizza per creare il proxy API esposto agli sviluppatori.

Il proxy API disaccoppia l'implementazione del servizio di backend dall'API utilizzata dagli sviluppatori. In questo modo, gli sviluppatori sono protetti da modifiche future ai servizi di backend. Man mano che aggiorni i servizi di backend, gli sviluppatori, isolati da queste modifiche, possono continuare a chiamare l'API senza interruzioni.

Questo argomento fornisce informazioni sui vari tipi di proxy e sulle relative impostazioni. Per istruzioni passo passo sulla creazione di proxy, consulta i seguenti argomenti:

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

Creazione di un proxy API utilizzando la UI

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

UI Apigee nella console Google Cloud

1. Nella console Google Cloud , vai alla pagina Sviluppo proxy > Proxy API.

   Vai ai proxy API

2. Fai clic su + Crea.

UI classica

Per accedere alla procedura guidata Crea proxy utilizzando l'interfaccia utente Apigee, segui questi passaggi:

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

La procedura guidata Crea proxy mostra e ti guida nei passaggi per generare e aggiungere funzionalità minime a un proxy API.

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

Tipo	Descrizione
Reverse proxy (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 Creazione di un proxy inverso per un servizio HTTP più avanti in questa sezione. Fai clic su Utilizza specifica OpenAPI per generare il proxy da una specifica OpenAPI valida. Per saperne di più su questa opzione, consulta la sezione Utilizzare le specifiche OpenAPI per generare proxy più avanti in questa sezione.
Nessun target	Un proxy API senza backend API ("nessuna destinazione"). Analogamente alla creazione di un proxy inverso per un servizio HTTP descritta in precedenza, tranne per il fatto che non specificherai un'API esistente quando definisci i dettagli del proxy API. Fai clic su Utilizza specifica OpenAPI per generare il proxy da una specifica OpenAPI valida. Per saperne di più su questa opzione, consulta la sezione Utilizzare le specifiche OpenAPI per generare proxy più avanti in questa sezione.
Carica bundle proxy	Un bundle proxy API esistente (ad esempio uno dei proxy API di esempio disponibili su GitHub). Consulta Importazione di un proxy API da un pacchetto di proxy API.
Proxy con eventi inviati dal server (SSE)	Un proxy API che include un EventFlow per lo streaming di eventi inviati dal server (SSE). Per ulteriori informazioni, vedi Eventi inviati dal server in streaming.

Le sezioni seguenti descrivono 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.
• Il percorso URI che identifica in modo univoco l'API che verrà esposta dal proxy API alle app consumer.

L'URL del servizio di backend in genere rappresenta un'applicazione abilitata al servizio di proprietà della tua organizzazione. Può anche puntare a un'API disponibile pubblicamente. L'API o il servizio possono essere sotto il tuo controllo (ad esempio, un'applicazioneRUR interna o un'applicazione Rails nel cloud) oppure possono 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 Crea proxy e aver selezionato un tipo di proxy:

Campo	Descrizione
Nome	Nome visualizzato per l'API. Specifica caratteri alfanumerici, trattino (-) o trattino basso (_).
Percorso base	Frammento URI che viene visualizzato dopo l'indirizzo http://[host] o https://[host] del tuo proxy API. Apigee utilizza l'URI del percorso di base per abbinare e instradare i messaggi di richiesta in entrata al proxy API corretto. Nota: il percorso di base del proxy API corrisponde per impostazione predefinita al valore specificato per il campo Name convertito in minuscolo. Dopo il percorso di base, seguono gli URL delle risorse aggiuntive. La struttura completa dell'URL che i client utilizzano 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 con lo stesso percorso di base. Se modifichi un proxy API di cui è stato eseguito il deployment e imposti il percorso di base sullo stesso valore del percorso di base di un altro proxy API, Apigee annulla automaticamente il deployment del 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 i caratteri jolly nei percorsi di base Utilizza uno o più caratteri jolly /*/ nei percorsi di base dei proxy API per preparare i tuoi proxy API per il futuro. Ad esempio, un percorso di base /team/*/members consente ai client di chiamare https://[host]/team/blue/members e https://[host]/team/green/members senza che tu debba creare nuovi proxy API per supportare nuovi team. Tieni presente che /**/ non è supportato.
Descrizione	(Facoltativo) Descrizione dell'API.
Target (API esistente)	URL del servizio di backend richiamato da questo proxy API.

Importazione di un proxy API da un pacchetto di proxy API

Nota:quando importi un proxy API da un pacchetto di proxy API, sei responsabile della configurazione della sicurezza e dell'aggiunta di criteri al pacchetto. L'interfaccia utente non ti chiede di aggiungere sicurezza o criteri durante l'importazione del bundle, come descritto in Aggiunta della sicurezza più avanti in questa sezione.

Spesso definisci i proxy API come una raccolta di file XML, insieme a qualsiasi altro file di supporto. Definendo i proxy API come un insieme di file esterni ad Apigee, puoi gestirli in un sistema di controllo del codice sorgente e poi importarli in Apigee per i test e il deployment.

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

1. Accedi alla procedura guidata Crea proxy come descritto in Creazione di un proxy API utilizzando la UI.
2. Specifica i dettagli del bundle del proxy API.

UI Apigee nella console Google Cloud

1. Nel menu Modello proxy, seleziona Carica bundle proxy.
2. Nella sezione Dettagli proxy, inserisci il Nome proxy, carica il file zip e fai clic su Avanti.
3. Nella sezione Deployment, seleziona gli ambienti di deployment, se vuoi, e fai clic su Crea.

UI classica

1. Fai clic su Carica bundle proxy.

2. Nella pagina Carica bundle proxy della procedura guidata per i proxy, inserisci le seguenti informazioni:

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

3. Fai clic su Avanti.

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

   Viene visualizzata una conferma che indica che il nuovo proxy API è stato creato correttamente.

5. 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 solo con supporto passthrough al momento. Con il supporto passthrough, il payload gRPC è opaco ad Apigee e il traffico viene instradato dal client gRPC al server di destinazione gRPC preconfigurato nella configurazione di destinazione.

Al momento, i proxy API gRPC di Apigee:

• Supporta le richieste gRPC unarie.
• Non puoi utilizzare criteri che influiscono sul payload.
• Può essere utilizzato in prodotti API non associati a proxy GraphQL o REST. Le quote specifiche del prodotto API e altre impostazioni di funzionamento si applicano a tutti i proxy del prodotto.
• Non sono supportati in Apigee hybrid.
• Utilizza due variabili di flusso specifiche di gRPC: request.grpc.rpc.name e request.grpc.service.name.
• Può essere monitorato con queste variabili Apigee Analytics specifiche di gRPC: x_apigee_grpc_rpc_name, x_apigee_grpc_service_name e x_apigee_grpc_status.
• Restituisce codici di stato gRPC.

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

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

Nota: la configurazione del proxy gRPC tramite la UI di Apigee è supportata solo tramite la UI di Apigee in Cloud Console, non altre console Apigee.

Utilizzo dei comandi gcloud CLI per creare il routing per gRPC

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

Questa sezione non è una guida completa per la creazione del routing. Questi esempi potrebbero non essere adatti a tutti i casi d'uso. Inoltre, queste istruzioni presuppongono la familiarità con il routing esterno (MIG) e la configurazione gRPC del bilanciatore del carico cloud.

Imposta 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

Esempio di comandi gcloud CLI per la creazione del routing per i proxy gRPC utilizzando i nuovi bilanciatori del carico

Questa sezione mostra comandi di esempio per la creazione di proxy gRPC utilizzando la gcloud CLI e un nuovo bilanciatore del carico. Le istruzioni includono la configurazione del bilanciatore del carico, di un server di destinazione e di un MIG.

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

Definisci 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

Verifica che il certificato sia stato eseguito il provisioning

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. Aggiungi i MIG al servizio di backend. In questo esempio riutilizziamo il MIG, ma potresti anche creare una nuova coppia di 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 --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 hai già una mappa degli URL. In questo caso, assicurati di modificare la mappa in base ai requisiti riportati di seguito anziché sovrascriverla.
   

   Crea un file YAML o utilizza il file esistente, in /tmp/apigee-map.yaml, con questa 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 sull'intestazione:

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

Crea un proxy HTTPS di destinazione per il 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

Comandi gcloud CLI di esempio per la creazione del routing per i proxy gRPC per i bilanciatori del carico esistenti

Questa sezione mostra comandi di esempio per la creazione di proxy gRPC utilizzando la CLI gcloud e un bilanciatore del carico esistente. Le istruzioni includono la configurazione del bilanciatore del carico, di un server di destinazione e di un MIG.

Crea un altro servizio di backend per HTTP/2

# 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 MIG

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 bilanciatore del carico Google esistente di Apigee

gcloud compute url-maps list -project $PROJECT_ID

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

gcloud compute url-maps export APIGEE_URL_MAP_NAME -project $PROJECT_ID

Crea un file YAML della mappa URL di bilanciamento del carico

Se hai già una mappa URL esistente, unisci questa configurazione. Altrimenti, crea un file YAML 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

Aggiunta della sicurezza

La sicurezza del proxy viene ottenuta aggiungendo una policy al proxy. Per ulteriori informazioni sulle norme, consulta Che cosa sono le norme? Per saperne di più sulla sicurezza, consulta Proteggere un proxy.

Per aggiungere un criterio di sicurezza al proxy:

Apigee nella console Cloud

1. Crea un proxy come descritto in Creazione di un proxy API.
2. Aggiungi una norma di sicurezza come descritto in una delle sezioni elencate in Proteggere un proxy. I criteri di sicurezza più comuni utilizzati sono le chiavi API e OAuth2.

UI Apigee classica

Nella pagina Norme comuni della procedura guidata Crea proxy, seleziona il tipo di 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 definendo. In risposta, la piattaforma API aggiunge una policy VerifyAPIKey e una policy AssignMessage al proxy API. Il criterio VerifyAPIKey convalida le chiavi API presentate dalle app che effettuano richieste. Il criterio AssignMessage rimuove la chiave API, fornita nella chiamata API come parametro di query, dalla 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 criterio per rimuovere il token di accesso dal messaggio prima di inoltrarlo al servizio di backend. Per scoprire come ottenere un token di accesso, consulta OAuth.
Pass through (nessuna autorizzazione)	Nessuna autorizzazione richiesta. Le richieste vengono trasmesse al backend senza alcun controllo di 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 effettuare richieste dirette a un altro dominio. Lo standard CORS definisce un insieme di intestazioni HTTP che i browser e i server web utilizzano per implementare la comunicazione tra domini.

Puoi aggiungere il supporto per CORS aggiungendo la policy CORS al PreFlow della richiesta di ProxyEndpoint.

Per informazioni più dettagliate sul supporto CORS, inclusa l'aggiunta del supporto preflight CORS a un proxy, vedi Aggiunta del supporto CORS a un proxy API.

Aggiunta di quote

Le quote proteggono il tuo servizio di backend dal traffico elevato in Quota. Consulta la sezione Quote. (Non disponibile se è selezionata l'autorizzazione pass-through.)

Utilizzo delle specifiche OpenAPI per generare proxy

Questa sezione descrive l'opzione Utilizza OpenAPI disponibile per la generazione da una specifica OpenAPI dei seguenti tipi di proxy API: inverso o senza target.

Che cos'è una specifica OpenAPI?

   "L'Open API Initiative (OAI) si concentra sulla creazione, l'evoluzione e la promozione di un formato di descrizione dell'API indipendente dal fornitore basato sulla specifica Swagger." Per ulteriori informazioni, consulta OpenAPI Initiative.

Una specifica OpenAPI utilizza un formato standard per descrivere un'API RESTful. Scritta in formato JSON o YAML, una specifica OpenAPI è leggibile dalla macchina, ma anche facile da leggere e comprendere per gli esseri umani. La specifica descrive gli elementi dell'API, ad esempio il percorso di base, i percorsi e i verbi, le intestazioni, i parametri di ricerca, le operazioni, i tipi di contenuti, le descrizioni delle risposte e altro ancora. Inoltre, una specifica OpenAPI viene comunemente utilizzata per generare la documentazione API.

Il seguente frammento di una specifica OpenAPI descrive il servizio di destinazione simulato di Apigee, http://mocktarget.apigee.net. Per ulteriori informazioni, consulta Specifica 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
...

Tramite la procedura guidata Crea proxy, puoi importare una specifica OpenAPI e utilizzarla per generare un proxy API. Una volta generato il proxy, puoi utilizzare l'interfaccia utente Apigee per svilupparlo ulteriormente aggiungendo policy, implementando codice personalizzato e così via, proprio come qualsiasi proxy Apigee.

Creazione di un proxy API da una specifica OpenAPI

Crea i proxy API da una specifica OpenAPI. In pochi clic avrai un proxy API con percorsi, parametri, flussi condizionali ed endpoint di destinazione generati automaticamente. Poi, 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 senza target da una specifica OpenAPI. Per maggiori dettagli, consulta Creazione di un proxy API da una specifica OpenAPI.

Creazione di una nuova revisione di un proxy API

Per creare una nuova revisione di un proxy API:

1. Apri la UI Apigee.

Apigee nella console Cloud

Nella console Google Cloud , vai alla pagina Sviluppo proxy > Proxy API.

Vai ai proxy API

UI Apigee classica

1. Accedi alla UI Apigee.
2. Nella barra di navigazione, seleziona Sviluppa > Proxy API.
2. Fai clic sul proxy API nell'elenco che vuoi copiare.

3. Fai clic sulla scheda Sviluppa.

4. Seleziona il pulsante Salva e poi Salva come nuova revisione.

Backup di un proxy API

Puoi eseguire il backup di un proxy API esistente come insieme 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 di proxy API precedentemente in questa sezione. Per maggiori informazioni, consulta la pagina Download dei proxy API.

Creazione di un proxy API utilizzando l'API

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

Informazioni sull'assenza di proxy di destinazione

I proxy non di destinazione in Apigee sono utili quando vuoi elaborare le richieste all'interno di Apigee senza inoltrarle a un servizio di backend. È importante capire quando questo approccio è appropriato.

Casi d'uso comuni

• Interazione con i dati gestiti da Apigee: Un proxy senza target è utile nei casi in cui devi interagire solo con i dati gestiti da Apigee, ad esempio i dati archiviati in una mappa chiave/valore (KVM) o nella cache Apigee. Ad esempio, puoi utilizzare un proxy senza destinazione per recuperare dati, come dati di sessione utente o dati di configurazione, dalla KVM. In questo caso, non è necessario chiamare un servizio di backend. Tutto ciò che serve è una norma KeyValueMapOperations nel flusso del proxy. Un altro esempio è la richiesta di svuotamento della cache. Puoi farlo richiamando il criterio InvalidateCache, senza dover connetterti a una destinazione.
• Utilizzo di API simulate: puoi creare API simulate per simulare il comportamento delle API prima che l'implementazione del backend sia completata per consentire lo sviluppo del frontend in modo indipendente. Per scoprire di più sulla creazione di API simulate, consulta Proxy API di simulazione OpenAPI.
• Gestione dei token: Apigee può emettere token OAuthV2, operazione che in genere viene eseguita tramite un proxy senza target.
• Test del comportamento delle policy: un proxy senza target può essere utile quando vuoi provare le policy Apigee per testarne il comportamento.