Le Api- Application Programming Interface come preziosa opportunità da sfruttare per l’automazione dei processi interni, per ridurre i cicli di design, sviluppo e lancio di nuovi prodotti e servizi, ma anche per aumentare la collaboration interna ed esterna all’azienda.
Questo in sintesi il ruolo delle Api, che come ricordato anche in occasione della recente presentazione dei dati dell’Osservatorio Enteprise Application Governance, si inseriscono da protagoniste in un percorso di trasformazione delle modalità di integrazione dei sistemi e dei servizi, in quanto si sta passando dal vecchio modello di Enterprise service bus a quello delle interfacce applicative (standard e open) che incorporano tutte le funzionalità necessarie a unificare i diversi sistemi vecchi e nuovi, interni ed esterni all’It (figura 1).
Le ragioni per cui il concetto di Api sta acquisendo sempre maggiore importanza riguardano:
- l’aumento dei progetti open source e il sempre più diffuso approccio all’open innovation che per funzionare necessita di uno “strato di collegamento”;
- i limiti mostrati dallo sviluppo Soa-Service oriented architecture e il fatto che l’interfaccia di programmazione sta diventando a tutti gli effetti un’applicazione e rappresenta l’acceleratore della migrazione del legacy verso sistemi più flessibili.
![](https://d3alc7xa4w7z55.cloudfront.net/static/upload/105/0001/10573-articolo2_figura27.jpg)
Le interfacce di programmazione sono usate, dunque, oltre che per aumentare l’efficienza operativa e produttiva e portare innovazione e collaborazione in azienda, per implementare nuovi modelli di business e reddito. Le Api infatti sono spesso sfruttate per migliorare i processi di misura e controllo del business, in particolare quale layer software attraverso il quale impostare nuove metriche e set di Kpi. Questo quanto emerge in uno studio di Gartner in cui vengono anche indicate le domande da porsi per identificare gli elementi utili a costruire il proprio Api business model:
- strategia di business: optare per l’integrazione tra Network ed It oppure ragionare ad ampio spettro e pensare ad una ‘new digital platform’?
- tipologia di prodotto: sviluppare Api singole oppure pensare a prodotti ‘composti’ in grado di intervenire sull’integrazione tecnologica a più livelli?
- dinamiche di mercato: qui le possibilità sono innumerevoli: si può ragionare sul fronte della standardizzazione oppure, al contrario, sviluppare Api proprietarie pensando a nicchie di mercato o a particolari verticalizzazioni… e ancora al modello di accesso dei servizi (public, semipublic, private…);
- modelli di pricing: gli scenari sono innumerevoli e quindi, anche le possibilità di ‘monetizzazione’ (free, frremium, subsription, pay per use, pay per transaction, revenue share); forse è proprio su questo aspetto che service provider e partner dovranno sempre più ‘sedersi ad un tavolo comune’ e collaborare.
L’utilizzo delle Api consente, come si è detto, di aprire l’azienda al mondo esterno; si tratta in pratica di finestre aperte che se da un lato abilitano nuovi modelli di business, dall’altro, espongono a non pochi rischi se non adeguatamente gestite. Le seguenti best practice consentono di mettersi al riparo, o quanto meno, di mitigare i rischi:
- convalida dei parametri , la singola misura di protezione più efficace contro gli attacchi che sfruttano i dati inviati alle Api è la convalida di tutti i dati in entrata rispetto a una whitelist di valori previsti;
- applicazione del rilevamento delle minacce in genere si tratta di definire blacklist dei contenuti a rischio, come istruzioni Sql o tag script, la sfida sta nell’applicare efficacemente i criteri di blacklisting perché il rischio di “falsi positivi” è elevato;
- attivazione generalizzata dell’Ssl/Tls, per le Api il protocollo Ssl/Tls dovrebbe diventare la regola in quanto fornisce riservatezza e integrità su tutti i dati scambiati tra un client e un server: non solo deve essere attivato in ogni Api, ma deve essere configurato correttamente;
- separazione delle identità, in quanto l’identità dell’utente e dell’app sono elementi separati. Gli sviluppatori lato server devono quindi separare nettamente le identità degli utenti e le identità delle Api e prendere in considerazione anche l’autorizzazione basata su un contesto di identità ampio (utente, applicazione, device, posizione, orario ecc.);
- utilizzo di soluzioni collaudate: non ha senso creare un proprio framework di sicurezza per le Api, esistono ottime soluzioni commerciali per garantire la sicurezza delle Api, la vera sfida è applicarle.