Si prevede che il mercato delle API crescerà da 4,1 miliardi di dollari nel 2021 a 8,14 miliardi di dollari nel 2027. Questa crescita massiccia dimostra quanto stia aumentando l'utilizzo delle API, sia interne che esterne.
Questa crescita nell'uso delle API comporta anche sfide per la gestione delle API. Le organizzazioni hanno API interne, API esterne e API di terze parti in esecuzione contemporaneamente. Devono produrre e acquistare nuove API, aggiornare quelle attuali e ritirare quelle obsolete. Affinché l'uso delle API sia efficiente, è necessaria una strategia per gestire tutte le API. Ecco perché è necessaria la gestione del ciclo di vita delle API. La gestione del ciclo di vita delle API è un insieme di processi che aiutano gli sviluppatori a organizzare le API dalla fase di pianificazione alla fase finale, quando un'API viene ritirata.
Per una gestione efficace delle API, definite le regole per ogni fase e utilizzate un gateway API, un portale per gli sviluppatori e una dashboard per gestire senza problemi tutte le vostre API.
Quali sono le fasi del ciclo di vita di un'API?
Non esiste un consenso generale sul numero totale di fasi del ciclo di vita di un'API. Alcuni lo dividono in cinque, altri in tre, altri ancora in otto e così via. In base al numero di volte in cui le API passano da uno stato all'altro, abbiamo suddiviso il ciclo di vita delle API nelle seguenti 10 fasi:
1. Pianificazione
La fase di pianificazione è quella in cui lo sviluppatore definisce il motivo per cui sta costruendo l'API. Quando gli stakeholder aziendali richiedono nuove caratteristiche e funzionalità per il prodotto, il team di sviluppo raccoglie i requisiti e stabilisce gli obiettivi per l'API in base a tali esigenze.
Questa è anche la fase in cui gli sviluppatori creano diagrammi multipli su una lavagna o un'applicazione di sketching per visualizzare come funzionerà l'API e come si inserirà nell'ecosistema API.
2. Progettazione
La fase di progettazione è quella in cui si definisce l'architettura dell'API. Questa fase è importante perché la persona che progetta l'API non necessariamente la costruirà. Il progetto deve essere standardizzato per essere facilmente comprensibile a tutti i membri del team.
Esistono quattro architetture API:
- REST: Representational State Transfer, utilizzato per le applicazioni web e mobili.
- SOAP: Simple Object Access Protocol, utilizzato nei sistemi operativi.
- RPC: Remote Procedure Call, utilizzato per le applicazioni distribuite.
- GraphQL: Graph Query Language, utilizzato nelle applicazioni mobili.
Dei quattro tipi, REST e SOAP sono i più utilizzati.
Progettate API REST utilizzando le specifiche OpenAPI (OAS), un formato che descrive la sintassi e la struttura delle API, indipendentemente dal linguaggio di programmazione utilizzato per costruirle. Scrivete le specifiche in YAML o JSON e rendete l'API coerente con le linee guida di progettazione dell'organizzazione.
L'idea e i processi rimangono gli stessi per le API SOAP, ma invece delle specifiche OpenAPI, si usa il Web Services Description Language (WSDL), un linguaggio di descrizione delle interfacce basato su XML, per scrivere le specifiche dell'API.
3. Edificio
A questo punto, lo sviluppatore che lavora sull'API sa cosa deve fare l'API e come deve funzionare. Tutte le informazioni ricavate dalle fasi di pianificazione e progettazione sono documentate e accessibili alla persona che costruisce l'applicazione. La fase di costruzione è quella in cui gli sviluppatori scrivono il codice e danno vita all'API. Di seguito sono elencate alcune delle attività standard svolte in questa fase.
- Standardizzazione delle risposte a tutti i tipi di richieste, come 202: Richiesta accettata e 404: Risorsa non trovata.
- Costruire l'endpoint dell'API, ovvero l'URL in cui vengono ricevute le richieste dell'API.
- Specificare il tipo di richiesta che l'endpoint può ricevere, ad esempio (GET, POST, PUT, PATCH, DELETE).
- Paginazione per le richieste GET, in modo che se la query di ricerca restituisce 10.000 risultati, l'interfaccia mostra la pagina 1 su 100 e visualizza i primi 100 risultati.
- Implementare la cache sul lato client per ottenere prestazioni più veloci, in quanto alcune risorse possono essere memorizzate nella cache sul lato client per ridurre il carico del server.
Una volta sviluppata, l'API viene sottoposta al processo di test, in cui vengono utilizzati strumenti come SOAPUI e REST-assured, rispettivamente per le API SOAP e REST.
4. Assicurare
La sicurezza segue da vicino la fase di costruzione. In questa fase, gli sviluppatori criptano gli endpoint delle API utilizzando certificati SSL. Questo aiuta a prevenire gli attacchi degli hacker che cercano di ottenere nomi di server, framework, versioni e altre informazioni sensibili.
L'autenticazione e l'autorizzazione degli utenti sono protette da OAuth 2.0. L'autenticazione degli utenti diventa ancora più importante quando si tratta di API esterne. Infatti, chiunque abbia accesso all'API può utilizzarla per attaccare il sistema. Con metodi di autenticazione adeguati, solo le persone autorizzate possono utilizzare l'API. Per le API pubbliche e le API esterne, vengono definiti limiti di richiesta e di dimensione per proteggere l'API da attacchi DDoS.
5. Versione
Il versioning prevede che gli sviluppatori apportino modifiche all'API e ne creino una versione nuova e migliorata. Il versioning è necessario perché potrebbe essere necessario:
- Includere un nuovo tipo di dati che possono essere restituiti come risposta alle richieste.
- Aggiungere o rimuovere i tipi di richiesta e di risposta.
- Aggiungere altri endpoint.
Dopo la distribuzione della nuova versione, la vecchia viene lentamente ridimensionata e ritirata.
Di solito, gli sviluppatori includono il numero di versione dell'API nel suo percorso URI (Uniform Resource Identifier). Il percorso URI viene utilizzato per identificare l'API. La convenzione di denominazione utilizza il formato 'MAJOR.MINOR.PATCH' oltre all'URI. Quindi, se un'API ha 2.4.10 accanto al suo nome, significa che è la seconda versione principale, la quarta versione minore della seconda versione e la decima patch. Allo stesso modo, 1.0.0 è la prima versione principale e stabile di un'API.
6. Editoria
Pubblicare un'API significa renderla disponibile agli utenti per il consumo. Questi utenti possono essere i membri del vostro team nel caso di API interne, i vostri partner e clienti nel caso di API esterne, o chiunque nel mondo nel caso di un'API pubblica. Con la pubblicazione dell'API, si passa alla versione stabile.
7. Catalogazione
In questa fase, gli sviluppatori aggiungono l'API al catalogo API dell'azienda, ovvero la libreria di tutte le API dell'organizzazione. Il catalogo dovrebbe contenere anche la documentazione relativa alle fasi di pianificazione, progettazione, costruzione, versioning e altre fasi del ciclo di vita dell'API.
La catalogazione aiuta a centralizzare e organizzare l'infrastruttura API dell'organizzazione. Inoltre, rende più facile per i nuovi sviluppatori lavorare con le API e creare nuove versioni, perché tutte le informazioni di base di cui hanno bisogno sono disponibili in un unico luogo.
8. Osservare
Una volta che un'API viene pubblicata e le persone iniziano a usarla, gli sviluppatori impostano il monitoraggio per tenere d'occhio la disponibilità, l'utilizzo e le prestazioni per assicurarsi che funzioni come previsto. Alcune delle metriche utilizzate per osservare le prestazioni di un'API includono i tempi di attività, i tempi di inattività, i consumatori unici di API, le richieste al minuto e gli errori al minuto.
Per tenere traccia delle analisi API, è possibile creare una soluzione personalizzata o utilizzare strumenti come SnapLogic APIM.
9. Scala
Più persone utilizzano la vostra API, più risorse richiede il vostro server. Una maggiore adozione comporta un numero maggiore di richieste e un maggiore utilizzo di CPU e memoria. Per assicurarsi che l'API sia in grado di gestire un numero maggiore di chiamate da parte degli utenti, si può percorrere la strada del vertical scaling, ovvero aggiungere continuamente più memoria e processori più veloci. Tuttavia, il vertical scaling può diventare costoso nel tempo, poiché si continua ad acquistare nuovo hardware.
Il ridimensionamento orizzontale è un'alternativa migliore del ridimensionamento verticale. Si aggiungono nuovi server, si ospita l'API su più server e si utilizza il bilanciamento del carico per assicurarsi che tutti i server siano utilizzati allo stesso modo in termini di CPU e memoria. In questo modo, i costi rimangono sotto controllo, poiché non è necessario acquistare nuovo hardware con la stessa frequenza, e le risorse vengono utilizzate in modo efficiente.
10. In pensione
Di solito le API vengono ritirate quando è disponibile una versione migliore, quando ci sono problemi di sicurezza o troppi bug, o semplicemente non è conveniente mantenerle in vita. In tutti i casi, comunicare la decisione di ritirare l'API a tutti coloro che la utilizzano. Prima che Google ritirasse l'API Contatti nel gennaio 2022, ha annunciato che l'API era deprecata nel settembre 2020, dando agli utenti più di un anno per adattarsi.
Una corretta gestione delle versioni è utile anche per il ritiro di un'API, perché si può semplicemente chiedere agli utenti di passare alla versione consigliata e concedere loro qualche mese per farlo. Quando le versioni sono catalogate correttamente, è sempre possibile eseguire il rollback di una nuova versione e passare a una versione precedente, se necessario. Avere a disposizione per l'analisi le versioni più vecchie e ritirate può anche aiutare a risolvere i problemi ricorrenti con le diverse versioni dell'API.
4 strumenti per una gestione efficace del ciclo di vita delle API
Utilizzate i seguenti strumenti per assicurarvi che le vostre API soddisfino i requisiti aziendali e di conformità e siano riutilizzabili, accessibili e coerenti.
1. Portale degli sviluppatori
Un portale per sviluppatori è un repository di informazioni per gli sviluppatori esterni e interni che utilizzano le vostre API. Consideratelo come un archivio di dati e applicazioni self-service che contiene tutte le informazioni tecniche su tutte le API della vostra organizzazione.
Il vostro portale per gli sviluppatori dovrebbe disporre di documentazione e guide API, nonché di un forum in cui gli sviluppatori possano porre domande e partecipare alle discussioni.
- La documentazione è utile per tutte le dieci fasi del ciclo di vita dell'API. Qualsiasi sviluppatore che debba apportare modifiche a un'API può accedere al portale degli sviluppatori e ottenere tutte le informazioni di base di cui ha bisogno.
- Un forum all'interno del portale li aiuterà a interagire con altri sviluppatori che lavorano con le stesse API o con API simili. Per i piccoli team, un forum potrebbe non essere necessario. Tuttavia, se offrite API esterne e avete partner e clienti di diverse organizzazioni che utilizzano tali API, un forum può essere utile.
- Il portale per gli sviluppatori dovrebbe avere un catalogo API centrale, dove gli sviluppatori possono accedere a tutte le API correnti. Se avete centinaia di API interne in produzione, un catalogo API vi aiuterà a gestirle facilmente.
In alcuni casi, gli utenti finali esterni hanno accesso solo al forum e alle definizioni dell'API. A questi utenti viene solitamente fornito un modo per contattare gli sviluppatori dell'API in caso di problemi. Gli sviluppatori dell'API controllano il forum e rispondono alle domande degli utenti.
È possibile utilizzare un portale per sviluppatori personalizzabile come Blobr o creare il proprio portale per aiutare a catalogare e documentare le API.
2. Gateway API
Un gateway API è uno strumento che disaccoppia l'interfaccia rivolta all'utente finale dal backend dell'API. Scompone le singole richieste degli utenti in richieste multiple, le invia ai sistemi giusti, raccoglie le risorse in base alla richiesta e restituisce la risposta. Il gateway gestisce anche l'autenticazione degli utenti, il monitoraggio e l'analisi e la limitazione della velocità. Nei sistemi ad alto volume, dove arrivano centinaia, migliaia o decine di migliaia di richieste, è utile disaccoppiare la gestione delle richieste dall'elaborazione delle stesse.
È possibile gestire una o due API senza un gateway API, ma un gateway diventa necessario con più API. Si ottiene una maggiore sicurezza, in quanto gli endpoint API sensibili non sono esposti. I gateway API gestiscono anche la limitazione della velocità, l'autenticazione e l'autorizzazione degli utenti e il ridimensionamento.
Un gateway API è utile anche quando il team utilizza l'approccio DevOps, un'architettura a microservizi o un modello serverless.
Nell'approccio DevOps, le nuove versioni di più API vengono continuamente costruite, testate, distribuite e monitorate. Ogni volta che viene distribuita una nuova versione, anche la definizione dell 'API, che risiede nel gateway API, deve essere aggiornata. Il gateway aggiorna automaticamente le definizioni delle API quando vengono distribuite nuove versioni.
In un'architettura a microservizi, le applicazioni sono costruite come un gruppo di servizi liberamente accoppiati e distribuibili in modo indipendente. Supponiamo che un utente voglia informazioni complete su un prodotto da un'applicazione che utilizza un'architettura a microservizi. La sua richiesta di ottenere tali informazioni dovrà essere suddivisa in più richieste, perché le informazioni complete sul prodotto in un'architettura a microservizi non risiedono in un unico luogo. Nei sistemi ad alto volume che non utilizzano un gateway API, gli sviluppatori dovranno creare una soluzione personalizzata per suddividere tali richieste. Poiché i gateway API suddividono le richieste in arrivo in richieste più piccole, l'architettura a microservizi e i gateway API funzionano bene insieme.
Un modello serverless o un'architettura applicativa serverless è un modo per costruire applicazioni in cloud. Gli sviluppatori che utilizzano questo modello non gestiscono i server; il provider di cloud imposta i server e li configura e scala secondo le necessità. I gateway API funzionano con i framework serverless e possono essere configurati per bilanciare i carichi delle richieste indirizzando richieste specifiche a determinati server virtuali.
I gateway API sono un unico punto di ingresso per tutte le richieste degli utenti e per questo possono rappresentare un singolo punto di guasto. Per ridurre al minimo questo rischio, configurate il gateway API per un cluster ad alta disponibilità. I cluster ad alta disponibilità consistono in archivi di dati distribuiti e istanze multiple del servizio gateway in esecuzione su più server. Più server ci sono nel cluster, più si riduce il rischio di interruzioni del sistema.
È possibile utilizzare il gateway API di SnapLogic o costruirne uno proprio.
3. Cruscotto API
Una dashboard API, in cui è possibile visualizzare l'utilizzo delle API e le principali metriche API, aiuta a identificare i problemi con le API live e a risolverli in modo proattivo.
Il monitoraggio delle prestazioni e delle metriche di utilizzo delle API, come le richieste al minuto (RPM), la latenza media e massima, gli errori al minuto, l'uptime, l'utilizzo della CPU e della memoria, fa parte della fase di "osservazione" del ciclo di vita delle API. Tutti questi dati fanno ancora parte dell'ecosistema API senza un cruscotto API. I dati sono ancora accessibili attraverso il gateway API. Ma per accedervi, è necessario creare un software personalizzato che recuperi i dati dal gateway.
Una dashboard API può aiutarvi a tracciare, visualizzare e analizzare i dati più importanti per voi. Inoltre, rende l'accesso alle metriche API più semplice e facile da usare. Idealmente, il dashboard dovrebbe ricevere dati in tempo reale dal gateway API.
Considerate il cruscotto API della piattaforma CRM Zoho. Aiuta gli utenti a monitorare l'utilizzo delle proprie API. Sebbene si tratti di una dashboard rivolta ai clienti, è possibile utilizzarne una anche per le API interne o per le API esterne private per tenere traccia dei dati importanti per l'azienda.
Utilizzate Databox per creare un cruscotto personalizzato o costruite il vostro.
4. Utilizzare piattaforme iPaaS che supportino la gestione del ciclo di vita delle API
La piattaforma di integrazione come servizio (iPaaS) aiuta a integrare l'intero ecosistema software in modo che i dati generati dall'organizzazione possano essere protetti e preparati per l'analisi. Tutte le pipeline di dati dell'organizzazione sono automatizzate e gestite dalla piattaforma iPaaS utilizzata. La strategia iPaaS comprende tutti gli asset digitali, comprese le API. Invece di utilizzare strumenti diversi per l'integrazione delle applicazioni e la gestione del ciclo di vita delle API, utilizzate una piattaforma di integrazione che supporti tutte le dieci fasi del ciclo di vita delle API.
Tuttavia, dovrete costruire la vostra strategia iPaaS e la strategia di gestione del ciclo di vita delle API separatamente. Questo perché l'iPaaS si concentra maggiormente sull'automazione dei processi e sull'integrazione del software, mentre la gestione del ciclo di vita delle API si concentra sulla creazione, l'utilizzo e la manutenzione delle API. Se lo strumento iPaaS supporta entrambi, è possibile gestire le integrazioni e la gestione del ciclo di vita delle API in modo più efficiente.
Trasformare la gestione del ciclo di vita delle API con SnapLogic
SnapLogic è una piattaforma di integrazione low-code/no-code e una piattaforma di gestione delle API riunite in un'unica soluzione. È possibile creare pipeline di integrazione come API REST, importare specifiche OpenAPI e gestire queste API interne insieme a quelle esterne e di terze parti, il tutto senza lasciare la piattaforma SnapLogic. La nostra piattaforma di gestione delle API offre una soluzione completa di gestione del ciclo di vita delle API che consente di accedere a dashboard delle API, a un portale self-service per gli sviluppatori di API e di evitare la dispersione degli strumenti.
Utilizzate la nostra piattaforma all-in-one per ottenere il controllo completo su ogni fase del ciclo di vita delle API, dalla pianificazione al ritiro. Per ulteriori informazioni sulla soluzione di gestione delle API di SnapLogic, cliccate qui.
