Benvenuti a un altro episodio delle pillole di conoscenza Microsoft. Sono il vostro ospite Mirko Pitt. L'argomento di oggi è uno di quelli che quasi tutti hanno sentito nominare ma che pochi comprendono davvero. Le API. Probabilmente avrete sentito questo termine usato molto spesso. È una di quelle parole tecnologiche che la gente usa quando vuole sembrare esperta. La verità è che le API sono in realtà semplici. Sono solo un modo in cui un software comunica con un altro. Il tuo telefono richiede dati a un server. Server è l'indietro. Questa è una chiamata API. Ora immaginate di avere 20 API o 50 o 100. Ognuna potrebbe usare un'autenticazione diversa. Limiti di velocità differenti. Documentazioni varie, se presenti. Improvvisamente ciò che era iniziato come una semplice conversazione tra due app diventa un caos totale. Senza un gestore centrale ogni team reinventa la ruota. Un team costruisce il proprio sistema di autenticazione e un altro il proprio logging. Le alcune di sicurezza poi non. Gli sviluppatori si confondono su cosa faccia ogni API e non si ha una visione unica di ciò che accade nel sistema. Agile API Management risolve questo problema. Ti fornisce un centro di controllo. Pensalo come un attore di controllo del traffico aereo per le tue API. Alla fine di questo episodio capirai cos'è perché è importante e come si incastrano tutti i pezzi. Prendete il vostro caffè e iniziamo. Il problema troppe API nessun controllo. Ecco la realtà del software moderno. Dieci anni fa probabilmente avevi un'unica grande applicazione. Un monolite. Un database. Un API semplice. Oggi quella stessa applicazione potrebbe essere suddivisa in dozzine di microservizi.

Ogni servizio gestisce una cosa. Account utente, pagamenti, inventario, notifiche e dispone la propria API. All'improvviso hai 10, 50, 100 punti di ingresso diversi nel tuo sistema. Ora immagina di essere uno sviluppatore che cerca di costruire qualcosa usando queste API. Devi trovare ciascuna di esse e capire come autenticarti. Alcune usano chiavi API, altre o out, altre ancora nulla. Devi gestire manualmente rate limiting rischi di venire bloccato. Devi comprendere il formato dati che ciascuno richiede. È estenuante. La situazione peggiora dal punto di vista operativo. Senza un gateway centrale ogni team deve aggiungere sicurezza e log al proprio servizio manualmente. Alcuni team lavorano bene, altri dimentichano di registrare gli errori. Alcuni non convalidano affatto l'input. È incoerente, soggetto a errori. Un incubo di sicurezza pronto ad accadere. La conformità diventa quasi impossibile. Devi dimostrare chi ha avuto accesso a cose e quando? Buona fortuna estrale audit trail da 20 servizi diversi, ognuno con il proprio formato di log. Devi sapere quante chiamate API hai gestito il tuo sistema il mese scorso? Stai mettendo insieme metriche da una dozzina di dashboard diversi.

Fatto questo. Man mano che scali questo non è solo un problema. Non lo sta con il suo mondo. Non puoi aggiungere più sviluppatori, più servizi o più clienti senza un punto di controllo centrale. Pensalo come a un edificio. Immagina che ogni stanza abbia una serratura diversa. Non c'è una reception, un elenco. I visitatori vagano cercando la porta giusta, frustrati finendo per rinunciare. Caos totale. Questo è il problema che la gestione delle API è stata progettata per risolvere. Cos'è Azure API Management? La torre di controllo. Allora, cos'è esattamente Azure API Management? Ecco la definizione più semplice. È un servizio gestito che si colloca tra le tue API di backend e le app, i siti, i dispositivi e i partner che le usano. Ma attenzione, non è solo un proxy. Un proxy inoltre al traffico e basta. Azure API Management copre l'intero ciclo di vita delle tue API. Pubblicazione, sicurezza, monitoraggio e infine il ritiro. È un centro completo. Analizziamolo in tre componenti principali. Primo è il gateway. Questa è la porta d'ingresso. Ogni richiesta in arrivo da un app o un sito colpisce prima il gateway, mai direttamente il tuo backend. Il gateway elabora la richiesta, applica le policy impostate, raccoglie metriche e la inoltre al servizio corretto. Immaginalo come un vigile urbano. Poi c'è il piano di gestione. È qui che definisci tutto. Le tue API, le policy prodotti, le sottoscrizioni. Lo fai tramite il portale Azure, la riga di comando, l'infrastruttura come codice, come bicep, terraforma. È la sala controllo dove configuri come funziona ogni cosa. I poli per gli sviluppatori. Un sito self-service dove gli sviluppatori, in termi ed esterni, scoprono API, leggono documentazione, ottengono chiavi e testano chiamate. Niente più PDF inviati via email. Ecco un'analogia utile. Pensa a un aeroporto moderno e la pista di atterraggio. Ogni aereo atterra prima lì. Il piano di gestione è la torre di controllo. Dirige il traffico, stabilisce regole e monitora tutto. È il portale per gli sviluppatori e tabellano informativi. I piloti lo controllano prima di volare e trovano tutte le info necessarie senza chiedere a nessuno. Ora concentriamoci sul gateway. È la parte con cui le tue app comunicano e dove avviene la vera magia. Il gateway è la porta all'interesse delle tue API. Parliamo del gateway perché è questa parte con cui le tue app comunicano realmente. Ogni richiesta da un'app mobile, un sito web o un dispositivo IoT colpisce prima il gateway, ma il tuo backend è direttamente. È proprio questo il punto. Il gateway si posiziona davanti e funge da un unico punto di ingresso. Il gateway può applicare policy prima di inoltrare la richiesta. Le policy sono regole che scrivi in XML o JSON come limitazione del traffico, filtraggio IP, riscrittura degli header e controlli di autenticazione. Il tutto senza modificare una sola riga del tuo codice backend. Con esempio concreto. Diciamo che hai un livello gratuito e un premium per la tua IP. Con una policy puoi limitare gli utenti gratuiti a 5 richieste al minuto, mentre quelli premium ne ottengono 100. Il tuo backend non nota mai la differenza. Elabora semplicemente le richieste. Il gateway gestisce l'applicazione delle regole. Il gateway gestisce anche la memorizzazione. Se i dati vengono richiesti ripetutamente, come un elenco di prodotti che cambia raramente, il gateway può memorizzare la risposta e fornirla direttamente. Non c'è bisogno di disturbare affatto il backend, che significa risposte più rapide e meno carico sui tuoi server. Può anche trasformare i dati. Il tuo backend potrebbe restituire XML, ma la tua app mobile si aspetta acceso.

Il gateway può convertirle al volo. Il tuo backend non deve cambiare, nemmeno la tua app deve farlo. Il gateway gestisce la traduzione. Registra ogni chiamata, ogni richiesta, ogni risposta, ogni errore. Ottiene una traccia di controllo completa di chi ha chiamato cosa, quando e cosa è successo. Solo questo vale il prezzo del biglietto per la conformità. Se hai un pubblico globale puoi distribuire il gateway in più regioni. Il traffico viene ingrizzato automaticamente a quella più vicina, il che offre una latenza inferiore e un'esperienza migliore. Un'altra cosa, il gateway nasconde il tuo vero URL backend. I client vedono solo l'indirizzo del gateway. I tuoi server backend rimangono nascosti da internet. È un enorme vantaggio per la sicurezza fin da subito. Policy, il motore che controlla tutto. Quindi che dire di quelle policy che ho menzionato? Sono il motore che rende la PIM davvero potente?

Una policy modifica il comportamento di una richiesta o di una risposta senza che tu debba mettere il codice del backend. Pensala come un wrapper attorno alla tua IP. Mentre il traffico scorre può aggiungere, rimuovere o modificare elementi automaticamente. Le policy possono essere eseguite in quattro punti del ciclo di vita della richiesta. Inbound, in entrata prima che la richiesta raggiunga il backend. Outbound, in uscita prima che la risposta arrivi al client. Backend, proprio prima che la richiesta colpisca il tuo servizio. E in caso di errore, quando qualcosa fallisce. Le operazioni in entrata comune includono la convalida di token JWT per verificare l'identità del chiamante, il controllo delle chiavi API, la riscrittura di URL e l'imitazione tramite indirizzo IP. Tutto ciò avviene prima che il tuo backend riceva una singola richiesta. Per l'operazione in uscita puoi trasformare il corpo della risposta. Trovare e sostituire testo, rimuovere i campi sensibili, cambiare formati. Puoi memorizzare nella cassa le risposte in modo che le richieste ripetute non raggiungano il tuo backend. Puoi persino eliminare intestazioni che rivelano informazioni in te. Ecco un esempio concreto. Supponi che la tua API restituisca descrizioni di prodotti con la parola blu ovunque. Puoi fare il rebranding e usare invece il giallo. Invece di modificare il codice del tuo backend, aggiungi una policy in uscita. Trova blu, sostituisci con giallo. Fatto.

Tuo backend non cambia mai. Le policy di limitazione della frequenza e di quota proteggono il tuo backend. Se l'app di qualcuno impazzisce e inizia a martellare la tua API 10.000 volte al secondo, la policy interviene e dice rallenta. Tuo backend rimane operativo. Ti serve una logica avanzata. Puoi scrivere espressioni C-Shark personalizzate all'interno delle policy. Vengono compilate per garantire le prestazioni. Non c'è alcun costo di esecuzione. Puoi cercare ruolo utente, calcolare i limiti di frequenza dinamici o trasformare risposte in base alle intestazioni della richiesta. Concetto chiave è questo. Le policy ti consentono di controllare il comportamento delle tue API senza toccare il codice che le esegue. Ciò significa modifiche più rapide, meno distribuzioni e meno rischi. Prodotti e abbonamenti. Il confezionamento delle API per i consumatori. Ora le tue API sono definite, le policy sono in atto e il gateway funziona a pieno ritmo. Ma come puoi dare a clienti diversi l'accesso a cose diverse? È qui che entra in gioco prodotti e abbonamenti. In Appim raggruppi le Appim qualcosa chiamato prodotto? Pensalo con un pacchetto. Potresti avere un prodotto gratuito che include solo le tue API di base. Magari solo accesso in lettura, poi un prodotto premium che include tutto, compreso operazioni di scrittura ed endpoint e amministrazione. Gli sviluppatori non si abbonano alle singole API e si abbonano a un prodotto. Quando si abbonano ricevono una chiave di abbonamento. Anzi due chiavi. Così puoi ruotarne una senza tempo in attività. Quella chiave è il loro pass per utilizzare qualsiasi API interno di quel prodotto. Sei tu a controllare come funzionano i abbonamenti. Prodotti possono richiedere approvazione. Puoi accettare manumento ogni abbonato oppure possono essere aperti al self-service. Chiunque si registra ottiene l'accesso immediato. Puoi anche includere termini legali che gli utenti devono accettare prima di abbonarsi. È importante se le tue API gestiscono dati sensibili. È così che monetizzi le API. Un prodotto gratuito con limiti di frequenza bassi, 5 chiamate al minuto. Un prodotto a pagamento con limiti più alti o più endpoint, 100 chiamate al minuto più l'accesso a funzionalità premium.

Al tuo backhand non importa. Il gateway applica i limiti in base al prodotto a cui il chiamante è effettuato l'abbonamento. Ecco un esempio concreto. Immagina di creare un'app per una conferenza. Crea un prodotto per i partecipanti con API per il programma delle sessioni, le biografie dei relatori e la mappa della sede. Poi un prodotto per gli sponsor che include anche API per la generazione di lead. Gli sponsor possono scansionare i badge dei partecipanti e ottenere informazioni di icono. Stesso backhand, prodotti diversi, livelli di accesso diversi. Quelle due chiavi di sottoscrizione sono progettate per la rotazione. Se una chiave viene compromessa ne generi una nuova. La seconda chiave ti permette di passare a quella nuova senza interrompersi. Genera la nuova chiave, aggiorna la tua app, revoca quella vecchia. Senta interruzione. Portale per sviluppatori, self-service per gli utenti delle API. Quindi hai configurato i tuoi prodotti API.

Ora gli sviluppatori devono trovare. Questo è il compito del portale per sviluppatore. Il portale per sviluppatore è un sito integrato in ogni istanza PM. Gli sviluppatori lo usano per esplorare le tue API, leggere la documentazione e testare gli endpoint in modo interattivo direttamente dal browser. Nessuna configurazione necessaria, niente scambio di me. C'è però un aspetto da considerare e di default non è pubblicato. Quando crei la tua istanza PM, il portale esiste ma nessuno può vederlo. Devi prima personalizzarlo e pubblicarlo. È voluto. Non vuoi mostrare al mondo un portale a metà? Puoi personalizzare i colori del brand, loghi e persino incorporare contenuti WordPress per un blog accanto alla documentazione delle tue. È completamente personalizzabile per adattarsi all'immagine della tua app. Vero valore è il self-service. Gli sviluppatori si registrano, ottengono le loro chiavi di sottoscrizione automaticamente e iniziano subito a chiamare le API. Niente email manuale, niente attese per l'approvazione, niente etiquette supporto per chiedere come ottenere una chiave. Fanno tutto da soli, il che riduce notevolmente il carico di supporto. Puoi anche pubblicare log delle modifiche note di rilascio. Quando aggiorni un API, gli sviluppatori la vedono nel portale senza sorprese. L'accesso può essere pubblico per chiunque abbia l'URL, oppure puoi limitarlo agli utenti del tuo tenant in 3D, così solo le persone della tua organizzazione possono navigare. Entrambe le opzioni esistono per diversi casi d'uso. Il portale per sviluppatori è ciò che rende la tua gestione API una vera piattaforma. Consideralo come la vetrina per le tue API. Senza di esso, gli sviluppatori devono cercare tre documenti e chiedere in giro. Con esso trovano ciò di cui hanno bisogno e iniziano a sviluppare. Sicurezza, autenticazione, autorizzazione e segreti. Tutta questa potenza è inutile se la sicurezza non è blindata. Quindi parliamo di come APIM gestisce identità, accesso e segreti. APIM supporta molteplici metodi di autenticazione. Più semplice è quello delle chiavi di sottoscrizione di cui abbiamo parlato prima. Tuttavia, per i sistemi in produzione servono soluzioni più robuste come OAuth 2.0, token JWT, certificati client o FIT3P. Si utilizzano questi livelli in base al grado di sensibilità della tua IP. Per la produzione, la best practice è usare OAuth 2.0 con Entry. Ecco come funziona. L'app client ottiene un token da Entry e lo invia con la richiesta API. APIM valida il token controllando firma, emittente, destinatario e scadenza. Se valido, APIM inoltre ha la richiesta al backend, includendo il token. Il backend si fida perché APIM ha già verificato tutto, non serve una nuova convalida. È un compito in meno che ogni servizio deve gestire.

Ora parliamo di segreti. Chiavi API, string di connessione, certificati. Non vanno inseriti nel codice delle policy o nel controllo versione. APIM offre una funzionalità chiamata valori denominati NIMB. Memorizzi segreti centralmente in APIM e li richiami per nome nelle tue policy. policy. Il valore reale non appare mai nel codice delle tue policy. Ancora meglio, puoi collegare i valori denominati ad Azure Key Vault. I segreti restano cifrati in Key Vault e APIM li recupera a runtime. Nessuno, nemmeno il team DevOps, vede il valore reale del segreto. Quando devi ruotare una chiave, l'aggiorni in Key Vault e APIM recepisce la modifica automaticamente. APIM supporta anche le identità gestite. Questo permette ad APIM di autenticarsi su altri servizi Azure, come Key Vault o API di backend, senza memorizzare i credenziali. Azzur gestisce l'identità, tu devi solo concedere l'autorizzazione. Per l'isolamento di rete puoi distribuire APIM all'interno di una rete virtuale. Questa è la versione premium. Oppure usa Azure Front Door. Il punto è che i tuoi servizi di backend non devono mai essere esposti direttamente a internet. APIM è l'unica cosa che il mondo esterno può vedere. Questo approccio a strati crea una difesa in profondità. Autenticazione al gateway, segreti in un volt, isolamento di rete attorno ai tuoi backend. Ogni livello rafforza quello successivo. Livelli di prezzo, quale fa per te? Quindi quanto costa? Esaminiamo i vari livelli. A consumo. Paghi per chiamata API senza costi mensili. Ideale per bassi volumi o carichi variabili come quando stai facendo prototipazione. Se non sai ancora cosa ti serve, parti da qui. Il livello developer offre un costo mensile fisso ridotto circa 50 dollari. Set di funzionalità completo ma senza SDA. Ideale per ambienti di sviluppo e test. Hai tutto ciò che offre la premium ma non è destinato alla produzione. Il livello basic è la produzione di base. Throughput inferiore, niente supporto per reti virtuali ma con un vero SLA. Ottimo per strumenti interni o piccoli progetti dove la rete privata non è critica. La maggior parte delle aziende esce il livello standard. Include supporto per rete virtuale, un SLA del 995% M, un buon throughput. Se gestisci API critiche per il business probabilmente è qui che ti stabilizzerai. Il livello premium è per le aziende globali che necessitano di massima affidabilità e reti private. Distribuzione multiregione gateway self-hosted SLA a 99,99% piena iniezione in rete virtuale. Parte da circa 2.700 al mese per unità. Microsoft ha introdotto anche i livelli V2, Basic V2, Standard V2 e Premium V2. Semplificano i prezzi con quote di richieste incluse e costi per milione di extra. Invece di monitorare più contatori è un pacchetto chiaro di richieste e paghi l'uso extra in semplici incrementi. Ecco come scegliere. Inizia con il livello developer per i test. Passa allo standard traduzione. Scegli il premium se ti serve a scala globale o rete privata. E ricorda puoi sempre migrare ad altri livelli in seguito. Inizia in piccolo e cresci man mano che le tue esigenze cambiano. Dove cosa dobbiamo trattare? La gestione API prende il caos di molte API e li unisce in un centro di controllo per gateway, policy, sicurezza ed esperienza sviluppatore. Il concetto chiave è che è molto più di un proxy. Immaginalo come il cervello e il sistema nervoso del tuo ecosistema API. Senza di esso ni team crea proprio sistemi di autenticazione, log e limitazione da frequente. Il risultato è in coerenza, lacune di sicurezza e nessuna visione unica di ciò che accade. Con esso ottieni coerenza, sicurezza e scalabilità senza reinventare la ruota per ogni servizio. Un semplice esercizio. Pensa a un API che esponi direttamente al momento. Magari un endpoint di funzione, è un servizio app. In che modo posizionare la gestione API davanti cambierebbe la tua postura di sicurezza e la capacità di monitorare l'uso? Anche solo riflettere su questo esercizio e ti mostrare il valore.

Prossimo passo, iscriviti al canale. Nei prossimi episodi mostreremo come importare un API, applicare la tua prima policy e monitorare l'uso in tempo reale. Passerai dalla teoria alla pratica. E se l'hai trovato utile, condividilo con chi sta creando un'app. Gli sparmerà mesi di mal di testa. Grazie attenzione.