Prima di creare un’API, gli sviluppatori devono decidere se quella API sarà aperta agli sviluppatori di terze parti tramite web oppure chiusa a tutti tranne che ai soggetti autorizzati all’interno. Anche se questa decisione riguarda unicamente la funzione prevista dell’API stessa, è allo stesso modo importante che sviluppatori e architetti prendano in considerazione alcuni importanti aspetti tecnici valutando anche l’impatto che la loro scelta potrebbe avere sulla gestione del loro portfolio API complessivo.
Per prendere la decisione giusta, è necessario prima di tutto comprendere le esatte implicazioni legate alla scelta di un’API aperta o chiusa da un punto di vista sia tecnico che di business e, in secondo luogo, affrontare i quattro aspetti critici che dovrebbero sempre essere presi in considerazione nelle scelte riguardanti l’esposizione di un’API.
API aperte vs. API chiuse
Le API aperte sono accessibili a sviluppatori di terze parti, partner commerciali, clienti e altri soggetti esterni tramite il web. Le aziende spesso le usano per permettere l’integrazione e la condivisione dei dati tra applicazioni e sistemi software rivolti all’esterno. Questo però comporta la presenza di un design sicuro e di una gestione pratica delle API, entrambi aspetti estremamente importanti quando si tratta di API aperte.
Le API chiuse, al contrario, sono quelle a cui si può accedere solo attraverso il sistema IT interno di un’organizzazione o da rete privata. Solitamente, le organizzazioni usano API chiuse per integrare le applicazioni line-of-business con i loro dati interni o sistemi back-end per via della loro connessione a sistemi business-critical e dati sensibili.
Non ci sono grandi differenze tra API aperte e chiuse in termini di funzionalità sottostanti o di processi di costruzione: gli sviluppatori possono ad esempio usare SOAP, REST e altri comuni modelli di progettazione API per costruire sia quelle aperte che quelle chiuse. Dal punto di vista operativo, un’API si integrerà con gateway API, dashboard di monitoraggio e altri strumenti di gestione standard, indipendentemente dal fatto che sia aperta o chiusa.
I primi fattori che gli sviluppatori e gli architetti dovrebbero considerare, riguardano temi come la sicurezza delle API, l’usabilità degli sviluppatori, i processi di versioning e la gestione degli errori. In queste aree, il livello di esposizione di un’API è invece molto importante e ognuna di esse dovrebbe influenzare fortemente la scelta tra mantenerla aperta oppure chiusa.
Sicurezza
La sicurezza è uno degli aspetti più importanti da considerare quando si sceglie tra API aperte o chiuse. Tutte le API dovrebbero teoricamente essere regolate da forti procedure di autenticazione e autorizzazione e gli sviluppatori dovrebbero sempre sforzarsi di applicare le policy in modo coerente, rivedendo le loro strategie di sicurezza API regolarmente per prevenire intrusioni indesiderate. Cambiano però le esigenze di protezione di un’API a seconda che essa sia aperta o chiusa.
Essendo disponibili solo per gli stakeholder interni, le API chiuse comportano un rischio minore per la sicurezza rispetto alle API aperte che sono invece esposte anche agli sviluppatori esterni. In pratica, uno sviluppatore interno malintenzionato (o un hacker abile) sarebbe in grado di infiltrarsi e abusare di un’API chiusa, purché abbia le giuste conoscenze o credenziali di accesso. ma è certamente meno probabile che accada rispetto alla situazione in cui le API sono aperte e quindi ufficialmente disponibili per tutti su web.
I potenziali danni legati a incidenti di sicurezza che coinvolgono le API aperte possono essere enormi. Gli attaccanti spesso usano API aperte poco sicure come vettori per violare i dati, in altri casi però preferiscono mandare in crash i server manipolando l’API e sommergendoli con continue chiamate e richieste di servizio.
Conoscono bene queste dinamiche aziende come Facebook, le cui API aperte sono state utilizzate dagli hacker per rubare dati dagli account in più di un’occasione. Detto ciò, non si sta spingendo gli sviluppatori a risparmiare sulla sicurezza delle API chiuse e neppure a considerare gli aspetti di sicurezza delle API aperte così critici da cancellarne i benefici che forniscono in termini di connessione con i clienti e i partner commerciali.
Ciò che deve essere semplicemente ricordato è che le API aperte comportano un onere di sicurezza più pesante sull’organizzazione, ed è quindi essenziale fare particolare attenzione a non aprire mai un’API che espone dati sensibili o si collega direttamente a sistemi business-critical.
Usabilità
La facilità d’uso è spesso ciò che maggiormente spinge verso la scelta di API aperte. Da un punto di vista aziendale, la loro usabilità gioca effettivamente un ruolo cruciale quando si ha l’intenzione di creare un forte ecosistema di sviluppatori di terze parti. In alcuni casi, la fruibilità di una certa API – o la sua mancanza – arriva persino ad impattare sul brand di un’azienda.
Al contrario, con le API chiuse, gli sviluppatori interni si devono accontentare del livello di usabilità che riescono a ottenere (livello scarso, di solito) e che potrebbe rendere gli sviluppatori esterni meno propensi a lavorare con la piattaforma di un’azienda.
Ciò non sempre accade però, dipende se ne vale la pena: in molti casi accettano di lavorare con un’API meno fruibile sapendo di poter contare, nel caso di quelle chiuse, di un maggior grado di affidabilità e sicurezza. In generale la fruibilità delle sue API aiuta un’azienda a rafforzare il rapporto con i partner ma non sempre è conveniente sacrificare la sicurezza di un’API chiusa per questo motivo.
Versioning
Quando si tratta di versioning, è spesso più facile effettuare aggiornamenti alle API chiuse che rimangono relativamente statiche. Non solo: sono molti meno gli sviluppatori che usano le API chiuse di un’azienda rispetto a quelle aperte, ed è quindi molto più comodo e semplice prevedere aggiornamenti e lanciare nuove versioni dell’API in modo coerente per tutti gli utenti, raccogliendo feedback utili quando le cose vanno male.
È molto più impattante l’effort per lanciare nuove versioni di un’API aperta e anche dei semplici aggiornamenti relativi alle funzionalità possono rivelarsi complessi, dato che gli sviluppatori devono fare in modo che le variazioni apportate non compromettano le funzionalità esistenti per un gran numero di utenti.
Sebbene sia importante per qualsiasi progetto API, in particolare per le API aperte è necessario prestare la dovuta attenzione alla documentazione di supporto, che dovrà essere comprensibile a un vasto pubblico di possibili utenti. Non si deve dare per scontato nulla, né lasciare che ci si affidi a supposizioni ma prestare attenzione in modo scrupoloso ai dettagli relativi soprattutto agli aggiornamenti, senza includere informazioni sensibili che potrebbe portare a una violazione.
Gestione degli errori
Il fallimento delle API o il degrado delle prestazioni è un problema a prescindere ma da un certo punto di vista il rischio è molto maggiore con un’API aperta perché un qualsiasi incidente potrebbe portare gli sviluppatori di terze parti a smettere completamente di usare l’API di un’azienda, con un forte impatto sull’intero business.
In caso di gravi problemi di prestazioni, le API chiuse interrompono la disponibilità delle applicazioni interne e dei servizi business-critical ma di solito gli sviluppatori hanno il pieno controllo della situazione perché sono interni e i workaround sono più facili da implementare.
Dal punto di vista della brand reputation complessiva e della fiducia all’interno della community dei developer, i problemi di prestazioni delle API aperte tendono a causare più danni ed è anche più impegnativo risolverli, dato che forzare delle modifiche alle applicazioni di terze parti è un processo complesso e laborioso.
Gli sviluppatori che scelgono un’API aperta devono quindi trovare un equilibrio tra il fornire aggiornamenti regolari per mantenere l’usabilità e il garantire che i cambiamenti siano un numero ragionevole.
Passaggio da API aperte ad API chiude (e viceversa)
È possibile per gli sviluppatori modificare l’accessibilità di un’API dopo la sua distribuzione ma non è mai facile, meglio quindi pensarci prima, durante il processo di progettazione. Non è una situazione comune, ma può capitare che gli sviluppatori di un’azienda distribuiscano un’API aperta e poi decidano di chiuderla a causa di un rischio a livello di cybersecurity.
Uno scenario del genere può presentarsi, per esempio, quando un’azienda distribuisce un’API senza pensare alla sua gestione a lungo termine o non riesce a identificare accuratamente i requisiti del core business, oppure quando lo scopo originale dell’API cambia e quello nuovo richiede che l’API sia chiusa al pubblico.
Non essendoci un modo semplice per modificare un’API da aperta a chiusa, gli sviluppatori dovranno seguire un approccio attento e sistematico. Prima di tutto dovranno assicurarsi che gli sviluppatori che lavorano con quell’API abbiano il tempo di adattarsi e poi annunciare il cambiamento il prima possibile, prendendo in considerazione la possibilità di offrire una versione più vecchia dell’API in oggetto che possa ancora fornire le funzionalità e le risorse che diversamente andrebbero per loro perse.
Quando si trasforma un’API aperta in chiusa, è particolarmente importante fornire una documentazione che spieghi chiaramente i passi da fare prima, durante e dopo la transizione. Altrimenti si crea un clima di frustrazione se si annuncia che l’API aperta sta diventando chiusa senza indicare agli sviluppatori i passi successivi da compiere.
Il rischio, se non la certezza, sarebbe quello di compromettere pesantemente le relazioni con gli sviluppatori esterni, danneggiando di conseguenza anche il proprio business tanto quanto accade con la carenza di usabilità.
Anche per aprire un’API chiusa, è importante rivelare i piani ben prima che ciò avvenga, in modo che i team di sviluppo interno abbiano il tempo di tracciare le integrazioni. La documentazione va sempre resa disponibile in anticipo, per permettere agli sviluppatori esterni di capire esattamente cosa saranno in grado di fare con l’API aperta o per identificare qualsiasi rischio potenziale legato al cambiamento implementato.
