Questa pagina si applica ad Apigee e Apigee hybrid.
Visualizza la documentazione di Apigee Edge.
Le seguenti sezioni riepilogano il ciclo di vita dello sviluppo delle API utilizzando Apigee.
Sviluppo di proxy API
Apigee supporta le seguenti opzioni per lo sviluppo iterativo di proxy API:
Per saperne di più sui proxy API, consulta Informazioni su API e proxy API.
Sviluppo cloud con Apigee
Sviluppa i tuoi proxy API utilizzando gli strumenti di modifica e debug dei proxy API forniti con Apigee. Mentre utilizzi un proxy API, Apigee salva le iterazioni della configurazione come revisioni.
Quando esegui il deployment di un proxy API, scegli una revisione specifica di cui eseguire il deployment. In genere, esegui il deployment della revisione più recente e, se necessario, ripristini una revisione precedente. Vedi Deployment dei proxy API.
Per iniziare a sviluppare i proxy API utilizzando Apigee, consulta Creazione di un proxy API semplice.
Sviluppo locale con Apigee in VS Code
Utilizza Apigee in Visual Studio Code (VS Code) per sviluppare i proxy API e verificare la funzionalità tramite test manuali e unitari (ad esempio, invia una richiesta e visualizza i risultati).
Dopo aver completato la convalida locale, esegui il deployment delle configurazioni proxy API come archivi nei tuoi ambienti Apigee. Vedi Deployment dei proxy API.
Per iniziare a sviluppare i tuoi proxy API in locale utilizzando Apigee in VS Code, consulta Creazione del primo proxy API utilizzando Apigee in VS Code.
Deployment dei proxy API
Puoi creare ambienti in cui eseguire il deployment dei proxy API. La distinzione tra i diversi ambienti è arbitraria: ogni ambiente è semplicemente identificato da un diverso insieme di indirizzi di rete (URL). L'obiettivo è fornirti un dominio in cui creare e verificare i proxy API prima che l'API venga esposta a sviluppatori esterni. Per saperne di più, vedi Informazioni sugli ambienti e sui gruppi di ambienti.
Se esegui il deployment delle tue API in più ambienti, puoi separare il traffico tra i proxy API su cui stai lavorando in un ambiente di test e quelli a cui le app esterne accedono in fase di runtime in un ambiente di produzione.
Apigee supporta i seguenti tipi di deployment in un ambiente:
Tipo | Description |
Proxy | Sviluppa e testa i proxy API nei tuoi ambienti di sviluppo Apigee, quindi eseguine il deployment in ambienti di produzione e test di integrazione Apigee. Vedi Deployment di un proxy API. |
Archivia | Sviluppa e testa i tuoi proxy API programmabili utilizzando Apigee in VS Code. |
Aggiunta di criteri
Apigee ti consente di programmare il comportamento delle API senza scrivere alcun codice, utilizzando i criteri. Un criterio è come un modulo che implementa una funzione di gestione limitata specifica. I criteri sono progettati per consentirti di aggiungere tipi comuni di funzionalità di gestione a un'API in modo semplice e affidabile. I criteri offrono funzionalità come sicurezza, limitazione di frequenza, trasformazione e mediazione, in modo da non dover programmare e gestire in autonomia questa funzionalità. Puoi anche scrivere script e codice personalizzati (come applicazioni JavaScript), che estendono la funzionalità proxy API e ti consentono di innovare oltre alle funzionalità di gestione di base supportate dai criteri di Apigee. Per maggiori informazioni sui criteri di Apigee, consulta Che cos'è un criterio?
Apigee fornisce criteri pronti all'uso per varie funzionalità come criteri di gestione del traffico, sicurezza, mediazione ed estensioni. Per visualizzare l'elenco completo dei criteri disponibili in Apigee, consulta la panoramica dei riferimenti dei criteri.
Promozione alla produzione
Sei tu a scegliere dove eseguire il deployment di un'API. Ad esempio, puoi promuovere una revisione in un ambiente di produzione per consentire agli sviluppatori di iniziare a utilizzare la tua API. Contemporaneamente, potresti eseguire l'iterazione di più revisioni in un ambiente locale o di test, in cui aggiungi funzionalità o criteri di ottimizzazione. Quando è tutto pronto, puoi eseguire il deployment della nuova revisione nell'ambiente di produzione, sovrascrivendo la revisione esistente nell'ambiente. Con questo metodo, puoi sempre rendere disponibile una revisione in tempo reale della tua API agli sviluppatori durante lo sviluppo e il test di nuove funzionalità.
Deployment degli script mediante l'API Apigee
Apigee fornisce un'API RESTful che ti consente di integrare il deployment e la gestione di proxy API nel ciclo di vita dello sviluppo del software (SDLC) della tua organizzazione. Ad esempio, per garantire che vengano soddisfatti i requisiti di sicurezza, affidabilità e coerenza, un utilizzo comune dell'API Apigee consiste nello scrivere script o codice che eseguono il deployment in modo programmatico dei proxy API e li promuovono da un ambiente all'altro, nell'ambito di un processo automatizzato più ampio.
Per ulteriori informazioni, consulta l'API Apigee.
Gestione delle risorse di ambiente
Gli ambienti forniscono la segregazione di dati e risorse. Ad esempio, puoi configurare cache diverse nei tuoi ambienti test
e production
alle quali possono accedere solo i proxy API in esecuzione in quell'ambiente. Inoltre, le chiavi API emesse in un ambiente di test non sono valide in un ambiente di produzione e viceversa.
Per un ulteriore controllo durante la promozione, ti consigliamo di eseguire l'iterazione solo sui proxy API in un ambiente di test e di apportare il numero minimo di modifiche necessarie ai proxy API di cui è stato eseguito il deployment in un ambiente di produzione.
Per farlo, devi assicurarti che alcune risorse associate a ciascun ambiente siano configurate in modo tale da poter rimanere statiche in una configurazione proxy API.
- Mappe chiave-valore (KVM): se l'ambito è l'ambiente, devi assicurarti che vengano utilizzate convenzioni di denominazione per consentire ai proxy API di archiviare i dati senza richiedere modifiche alla configurazione durante la promozione. Per maggiori informazioni, consulta la sezione Utilizzo delle mappe chiave-valore.
- URL di destinazione: è comune che i proxy API chiamino URL di backend diversi durante i test e la produzione. Puoi utilizzare le configurazioni di TargetServer per creare configurazioni TargetEndpoint indipendenti dall'ambiente. Per saperne di più, consulta
- Bilanciamento del carico tra server di backend (sviluppo nel cloud)
- Configurazione dei server di destinazione (sviluppo locale)
- Target callout di servizio: i callout di servizio possono utilizzare target diversi a seconda dell'ambiente se, ad esempio, un callout di servizio nell'ambiente di test utilizza un servizio demo. Consulta le norme sui callout di servizio.
Per rendere le configurazioni del proxy API indipendenti dall'ambiente, puoi anche utilizzare istruzioni condizionali.
Le istruzioni condizionali create con la variabile environment.name
possono essere utilizzate per valutare l'ambiente attuale prima di applicare un criterio o prima di eseguire il routing a un URL nel backend. Per maggiori informazioni, consulta
Condizioni con variabili di flusso.