Ciclo di sviluppo delle API

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Ogni organizzazione ha un ciclo di vita dello sviluppo software (SDLC) univoco. Spesso è necessario sincronizzare e allineare il deployment dei proxy API con le stesse procedure che utilizzi oggi per lo sviluppo, il test e il deployment di altre applicazioni.

I servizi API forniscono strumenti e API RESTful che ti consentono di integrare il deployment e la gestione dei proxy API nello SDLC della tua organizzazione. L'API RESTful viene comunemente utilizzata per scrivere script o codice che eseguono il deployment dei proxy API a livello di programmazione o che eseguono la migrazione dei proxy API da un ambiente all'altro, nell'ambito di un processo automatizzato più ampio che esegue anche il deployment o la migrazione di altre applicazioni. I servizi API non fanno supposizioni sul tuo ciclo di vita del software (o su quello di qualcun altro). Piuttosto, espone funzioni atomiche che possono essere coordinate dal team di sviluppo per automatizzare e ottimizzare il ciclo di vita dello sviluppo delle API.

Le API API Services sono documentate nel Riferimento API. Consulta la sezione Guida introduttiva al riferimento API.

Ambienti

Ogni organizzazione su Apigee Edge dispone di almeno due ambienti di deployment disponibili per i proxy API: "test" e "prod". La distinzione tra i due ambienti è arbitraria: ogni ambiente è identificato semplicemente da un insieme diverso 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.

Puoi sfruttare questi ambienti per sincronizzare lo sviluppo del proxy API elaborato con il tuo SDLC. Ogni ambiente è definito da un indirizzo di rete, in modo da poter isolare il traffico tra i proxy API su cui stai lavorando e quelli a cui le app accedono in fase di runtime. Gli indirizzi di rete disponibili per ogni ambiente sono definiti nell'insieme di VirtualHost disponibili in quell'ambiente.

Il protocollo TLS/SSL del server in entrata viene attivato automaticamente per ciascun ambiente. In ogni ambiente sono predefiniti due VirtualHost: default e secure. L'impostazione predefinita definisce un indirizzo HTTP, mentre Secure definisce un indirizzo HTTP/S, con TLS/SSL lato server preconfigurato. In una configurazione del proxy API, devi indicare su quali VirtualHost deve ascoltare ProxyEndpoint. Quando esegui la promozione in produzione, in genere disattivi HTTP rimuovendo default VirtualHost dalla configurazione del proxy API.

Ad esempio, il seguente ProxyEndpoint rimane in ascolto su HTTP e HTTPS.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Se elimini VirtualHost default dalla configurazione di ProxyEndpoint, crei un proxy API che ascolta solo su HTTPS e non su HTTP.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Per visualizzare gli VirtualHost disponibili in un ambiente, seleziona Ambienti nel menu principale dell'interfaccia utente di gestione.

Inoltre, gli ambienti assicurano la segregazione di dati e risorse. Ad esempio, puoi configurare cache diverse in test e produzione, a cui possono accedere solo i proxy API in esecuzione in quell'ambiente. Inoltre, le chiavi API emesse nell'ambiente di test non sono valide nell'ambiente di produzione e viceversa.

Deployment di proxy API negli ambienti

Quando crei un proxy API, devi decidere in quale ambiente lavorerai. Puoi scegliere di creare un nuovo proxy API in produzione, ma questa operazione è sconsigliata perché potresti esporre un'API agli sviluppatori prima che sia pronta. In generale, crea un proxy API in test che, dopo il test, promuovi l'ambiente prod.

Per maggiori informazioni, consulta la pagina Informazioni sul deployment.

Sviluppo iterativo in fase di test

Mentre lavori su un proxy API, API Services salva le iterazioni della configurazione come revisioni. Quando esegui il deployment di un proxy API, scegli una revisione specifica da eseguire. In genere, esegui il deployment della revisione più recente e, se necessario, ripristini il numero di revisione precedente. Puoi scegliere dove implementare queste revisioni. Ad esempio, puoi promuovere una revisione in produzione per consentire agli sviluppatori di iniziare a utilizzare la tua API. Contemporaneamente, potresti eseguire l'iterazione di più revisioni durante il test, al fine di aggiungere funzionalità o perfezionare i criteri. Poi, quando è tutto pronto, puoi eseguire il deployment della nuova revisione in produzione, sovrascrivendo la revisione esistente in quell'ambiente. Con questo metodo, puoi sempre avere a disposizione una revisione in tempo reale della tua API per gli sviluppatori durante lo sviluppo.

Promozione in produzione

Quando un proxy API è stato completamente implementato e testato, è pronto per essere promosso a "prod". La revisione del proxy API in fase di test verrà utilizzata per sovrascrivere la revisione del proxy API di cui è stato eseguito il deployment nella produzione.

API Services offre funzionalità per garantire il deployment senza problemi dei proxy API, riducendo al minimo l'impatto sulle app e sugli utenti finali durante la procedura di deployment.

Deployment di script

L'interfaccia utente di gestione di Apigee Edge ti consente di eseguire il deployment dei proxy API in produzione direttamente dal generatore di proxy API. Tuttavia, in molte situazioni i requisiti di sicurezza, affidabilità e coerenza richiedono che i team di sviluppo scrivano script per le procedure di deployment. Per farlo, puoi scrivere codice e script che richiamano l'API RESTful esposta dai servizi API.

Risorse dell'ambiente

Per un maggiore controllo durante la promozione, ti consigliamo di eseguire l'iterazione solo sui proxy API in test e di apportare il minor numero possibile di modifiche ai proxy API 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.

• URL di destinazione: capita spesso 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. Vedi Bilanciamento del carico tra server di backend.
• Cache e mappe chiave/valore: entrambe le risorse di persistenza hanno ambito per ambiente. Devi assicurarti di utilizzare convenzioni di denominazione per consentire ai proxy API di archiviare i dati senza richiedere modifiche alla configurazione durante la promozione. Consulta Creare e modificare una cache dell'ambiente.
• Target callout di servizio: i callout di servizio possono utilizzare target diversi a seconda dell'ambiente se, ad esempio, un ServiceCallout nell'ambiente di test utilizza un servizio demo. Consulta le norme relative ai callout di servizio.

Per rendere le configurazioni dei proxy API indipendenti dall'ambiente, puoi anche utilizzare le istruzioni conditional. L'istruzione condizionale creata con la variabile environment.name può essere impiegata per valutare l'ambiente corrente prima di applicare un criterio o prima di eseguire il routing a un URL sul backend.

Per ulteriori informazioni, consulta Informazioni sul deployment.