Tecniche per ottenere il controllo sulla proliferazione indisciplinata delle API
CasaCasa > Notizia > Tecniche per ottenere il controllo sulla proliferazione indisciplinata delle API

Tecniche per ottenere il controllo sulla proliferazione indisciplinata delle API

Aug 21, 2023

Immagini Getty

Se lasciato senza controllo, un ampio portafoglio di API può rapidamente diventare un grosso problema e una costosa responsabilità per le aziende. Senza una strategia API e una standardizzazione ben definite, le applicazioni possono facilmente sfuggire al controllo e causare la proliferazione delle API.

Quando si verifica una proliferazione delle API, possono insinuarsi inefficienze come sforzi di sviluppo duplicati su funzionalità applicative ridondanti, richiedendo maggiori investimenti per la manutenzione e aumentando la complessità del sistema. La necessità di compatibilità con le versioni precedenti per molti consumatori può essere estremamente complessa e costosa. Molteplici fonti di verità possono anche portare a conflitti di dati, con conseguenti esperienze insoddisfacenti e ambiguità che possono ridurre l'adozione.

In questo articolo esamineremo alcune strategie generali che i team software possono implementare per prevenire la proliferazione delle API o, se necessario, riprendere il controllo su un portafoglio API già mal gestito.

Gestire una proliferazione incontrollata di API richiede uno sforzo mirato da parte dei team software per garantire di poter mantenere al minimo la complessità complessiva, i costi di modifica e la manutenzione di emergenza.

Affrontare la proliferazione delle API inizia con la determinazione della portata complessiva dell'impatto di un'API sulle operazioni e sul consumo di risorse. Spesso le API possono interagire con entità software sia all'interno dell'organizzazione che all'esterno dei suoi confini. La portata dell'impatto delle API è spesso limitata quando i consumatori, interni o esterni, sono esplicitamente integrati con esse.

Le API disponibili pubblicamente possono rappresentare un grado significativamente più elevato di complessità di gestione. Oltre alla classificazione per ambito di impatto – che potrebbe includere un numero qualsiasi di componenti ed endpoint fuori dal controllo dell’organizzazione – una singola API pubblica può spesso incorporare più formati di dati, standard di sicurezza e protocolli di comunicazione. Pertanto, è imperativo identificare l’entità della frammentazione durante l’attuazione del contratto e del protocollo.

A volte, le API dovranno migrare tra i sistemi nel corso del loro ciclo di vita. Per consentire un percorso di transizione agevole, i team software dovranno preparare le API prima della migrazione per garantire che mantengano lo stato desiderato. Per ridurre i problemi di transizione, potrebbe anche essere necessario calibrare la migrazione in modo che le API migrino lentamente nel tempo anziché in blocco. Esistono alcune tecniche di base di controllo delle versioni API che possono tornare utili a questo proposito, ad esempio consentire ai consumatori di migrare a versioni più recenti mentre i contratti precedenti sono deprecati. I team possono anche creare librerie accessibili per i runtime più diffusi, creare livelli di compatibilità per le API più recenti o aggiungere flag di funzionalità specifiche del consumatore per supportare una migrazione senza interruzioni.

Una volta che il panorama esistente e il suo impatto saranno ben compresi, i passi successivi dovrebbero concentrarsi sulla convergenza degli standard esistenti. Questa fase può essere eseguita in tre "sottopassaggi", che esamineremo di seguito.

I team devono misurare e analizzare regolarmente l'utilizzo delle API in tutti gli ambienti. Le aree in cui esiste un controllo minimo o nullo sui consumatori API potrebbero richiedere l'assistenza di strumenti o piattaforme di gestione API che forniscano supporto per funzionalità come il mocking. Identifica le principali aree di esposizione, le funzionalità critiche e tutti i formati API esistenti.

Le API in portafogli di grandi dimensioni e non gestiti possono spesso mostrare comportamenti ridondanti che portano a fonti di informazioni e sforzi di sviluppo duplicati. È importante chiarire le ambiguità delle fonti tracciando forti confini di dominio per le classificazioni API e, cosa forse ancora più importante, le responsabilità di gestione. Ciò potrebbe richiedere la creazione di nuove API che siano "versioni consolidate" di quelle precedenti, la deprecazione delle API esistenti ritenute ridondanti o semplicemente l'aggiornamento dei contratti delle API esistenti per restringerne l'ambito.

Una volta avvenuto il consolidamento funzionale, è importante stabilire convenzioni definitive in linea con le esigenze e gli obiettivi del business che in definitiva tracceranno il percorso per le transizioni e i nuovi sviluppi. Documentare e tracciare questi rapporti contribuirà notevolmente alla costruzione di un consenso più ampio su aspetti come le strutture contrattuali e i protocolli sottostanti.