Ciclo di sviluppo delle API

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Le sezioni seguenti 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 sulle API e sui 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 lavori a un proxy API, Apigee salva le iterazioni della configurazione come revisioni.

Quando esegui il deployment di un proxy API, scegli una revisione specifica da eseguire. In genere, viene eseguito il deployment della revisione più recente e, se necessario, viene ripristinata 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 delle unità (ad esempio, invia una richiesta e visualizza i risultati).

Dopo aver completato la convalida locale, esegui il deployment delle configurazioni del proxy API come archivi nei tuoi ambienti Apigee. Vedi Deployment dei proxy API.

Per iniziare a sviluppare i proxy API localmente utilizzando Apigee in VS Code, consulta Creazione del tuo primo proxy API utilizzando Apigee in VS Code.

Deployment dei proxy API

Crea ambienti in cui eseguire il deployment dei proxy API. La distinzione tra i diversi ambienti è arbitraria: ogni ambiente viene identificato semplicemente da un diverso insieme di indirizzi di rete (URL). L'obiettivo è fornirti un dominio in cui puoi creare e verificare i proxy API prima che l'API venga esposta a sviluppatori esterni. Per saperne di più, consulta Informazioni su ambienti e 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 test e quelli a cui accedono le app esterne in fase di runtime in un ambiente produzione.

Apigee supporta i seguenti tipi di deployment in un ambiente:

Tipo Descrizione
Proxy Sviluppa e testa i proxy API negli ambienti di sviluppo Apigee, quindi esegui il deployment negli ambienti di test di integrazione e produzione di Apigee. Consulta Deployment di un proxy API.
Archivia Sviluppa e testa i tuoi proxy API programmabili utilizzando Apigee in VS Code.

Aggiunta di policy

Apigee ti consente di programmare il comportamento delle API senza scrivere codice, utilizzando i criteri. Un criterio è come un modulo che implementa una funzione di gestione specifica e limitata. Le norme sono progettate per consentirti di aggiungere facilmente e in modo affidabile tipi comuni di funzionalità di gestione a un'API. I criteri forniscono funzionalità come sicurezza, limitazione della frequenza, trasformazione e mediazione, consentendoti di non dover codificare e gestire questa funzionalità in autonomia. Puoi anche scrivere codice e script personalizzati (ad esempio applicazioni JavaScript) che estendono la funzionalità del proxy API e ti consentono di innovare al di sopra delle funzionalità di gestione di base supportate dai criteri Apigee. Per ulteriori informazioni sulle norme Apigee, consulta Che cos'è una norma?

Apigee fornisce criteri pronti all'uso per varie funzionalità, come gestione del traffico, sicurezza, mediazione e criteri di estensione. Per visualizzare l'elenco completo dei criteri disponibili in Apigee, consulta la panoramica del riferimento ai criteri.

Promozione in produzione

Scegli 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 lavorare con la tua API. Allo stesso tempo, potresti iterare più revisioni in un ambiente locale o di test, in cui aggiungi funzionalità o perfezioni le norme. Quando è tutto pronto, puoi eseguire il deployment della nuova revisione nell'ambiente di produzione, sovrascrivendo la revisione esistente. Utilizzando questo metodo, gli sviluppatori possono sempre disporre di una revisione live della tua API durante lo sviluppo e il test di nuove funzionalità.

Deployment di script utilizzando l'API Apigee

Apigee fornisce un'API RESTful che ti consente di integrare il deployment e la gestione dei 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 dei proxy API e li promuovono da un ambiente all'altro in modo programmatico, nell'ambito di un processo automatizzato più ampio.

Per saperne di più, consulta l'API Apigee.

Gestione delle risorse dell'ambiente

Gli ambienti forniscono la separazione di dati e risorse. Ad esempio, puoi configurare cache diverse negli ambienti test e production a cui possono accedere solo i proxy API eseguiti 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 maggiore controllo durante la promozione, ti consigliamo di eseguire l'iterazione sui proxy API solo in un ambiente di test e di apportare il minor numero di modifiche necessarie ai proxy API di cui è stato eseguito il deployment in un ambiente di produzione.

Per farlo, devi assicurarti che determinate risorse associate a ogni ambiente siano configurate in modo da poter rimanere statiche in una configurazione del 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 saperne di più, consulta 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 TargetServer per creare configurazioni TargetEndpoint indipendenti dall'ambiente. Per ulteriori informazioni, vedi
  • Target ServiceCallout: i callout di servizio possono utilizzare target diversi a seconda dell'ambiente, ad esempio se un ServiceCallout nell'ambiente di test utilizza un servizio demo. Consulta le norme relative alle estensioni di chiamata.

Per rendere le configurazioni dei 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 ulteriori informazioni, consulta la sezione Condizioni con variabili di flusso.