Strategia e architettura delle API: un approccio coordinato

Transcript

1 Strategia e architettura delle API: un approccio coordinato

2 Introduzione L'avvento delle API (interfacce di programmazione delle applicazioni) rappresenta al contempo un'opportunità di business e una sfida tecnologica. Per i leader di business, le API sono un'occasione per generare nuovi flussi di ricavi e massimizzare il valore offerto ai clienti. Ricade però sugli architetti aziendali la responsabilità di creare API che consentano di riutilizzare i sistemi backend in nuove applicazioni web e mobile. È fondamentale che tutti gli stakeholder comprendano la stretta correlazione tra gli obiettivi aziendali e le sfide tecniche di un programma API. Spetta ai manager del programma la responsabilità di comunicare con chiarezza gli obiettivi di business primari delle API proposte agli architetti che poi realizzeranno materialmente l'interfaccia. Gli architetti devono invece focalizzarsi su tali obiettivi durante le fasi di implementazione dell'infrastruttura API e di progettazione dell'interfaccia stessa. Tutte le decisioni tecniche devono contribuire alla creazione di un'interfaccia con la quale gli sviluppatori possano realizzare applicazioni client realmente apprezzate dagli utenti finali. Questo ebook delinea le best practice di progettazione di API orientate ai risultati che costituiranno la pietra miliare su cui si fonda il successo del programma API aziendale. 2

3 Parte 1: Dall'architettura SOA alle API Nel 21 secolo le aziende IT iniziavano a esporre database e applicazioni precedentemente organizzati in silos per consentire l'accesso a dati e funzionalità e il loro riutilizzo in nuovi sistemi, anche oltre i confini aziendali. Questa tendenza si è inizialmente manifestata nell'architettura orientata ai servizi (SOA); più recentemente abbiamo assistito alla proliferazione delle API orientate al web. In un certo senso i servizi web, elementi centrali dell'architettura SOA, sono come le API web: si tratta in entrambi i casi di interfacce utilizzate per esporre i sistemi backend. Le due tecnologie presentano tuttavia differenze sostanziali di cui occorre tener conto nelle decisioni progettuali di base. La differenza tecnica primaria è che i programmi SOA si focalizzano sulla creazione di servizi web che facilitano le integrazioni interne, server-to-server, mentre le API web puntano ad accelerare la creazione di applicazioni web e mobile spesso destinate all'interazione con i clienti. Figura 1: SOA e API a confronto SOA API Tendenzialmente i programmi SOA sono promossi dai reparti IT e finalizzati al risparmio sui costi, mentre i programmi API hanno origine solitamente dai reparti di business development e puntano a generare nuovi flussi di ricavi. $$$ Obiettivo di integrazione Incentivi per i progetti Interno o verso i partner Costi IT Esterno, spesso verso i clienti Flussi di ricavi per il business La maggior parte dei progetti SOA viene creata da e per gli architetti aziendali, per semplificare l'integrazione di sistemi eterogenei e la delivery di nuovi servizi IT. I programmi API hanno invece come obiettivo la soddisfazione delle esigenze degli sviluppatori delle applicazioni. Interfaccia con i clienti Architetti aziendali Sviluppatori di app 3

4 Parte 1: Dall'architettura SOA alle API Obiettivi della progettazione di API Malgrado le differenze delineate, molti programmi API hanno origine da precedenti iniziative SOA. I servizi web focalizzati sulle integrazioni interne o di partner vengono esposti agli sviluppatori sia all'interno che all'esterno dell'azienda. Durante il processo, i progettisti API devono ricordare che un programma API ha motivazioni e requisiti diversi rispetto a quelli che hanno portato le aziende a esporre i propri asset IT tramite i servizi web. Con questo principio ben presente, è possibile definire gli obiettivi generici di un progetto API come indicato di seguito: Abilitare il self-service per gli sviluppatori e gli utenti di app Ridurre le barriere di accesso alle risorse aziendali di valore Dare priorità alle esigenze e alle preferenze degli sviluppatori di app client Incoraggiare la collaborazione tra risorse interne ed esterne Tenere conto delle problematiche di sicurezza e scalabilità causate dall'esposizione degli asset IT sul mercato aperto Soprattutto, la progettazione API deve ottimizzare il valore di business dell'interfaccia. La seconda parte prende in esame come le API possono aggiungere valore al business. 4

5 Parte 2: La catena di valore delle API Le API possono non avere un valore intrinseco, ma apportano un enorme valore al business tramite i dati di backend e le funzionalità applicative che abilitano. In quest'ottica, l'api è un facilitatore che consente di riutilizzare i sistemi di grande valore aziendale nelle applicazioni per produrre un valore di business diretto. Benché questa sia una prospettiva utile, se osservata più da vicino diventa chiaro che un'api ben progettata è in realtà un connettore complesso e potente. Congiunge infatti numerose risorse aziendali: sistemi IT, collaboratori interni ed esterni, applicazioni client e clienti, il tutto finalizzato a realizzare più efficacemente il valore potenziale degli asset stessi, una condizione che possiamo definire "catena di valore delle API". È importante comprendere che un'api fornisce valore in questo modo così complesso, perché altrimenti si può perdere di vista il fatto che le API esistono per offrire valore di business e non efficienze tecniche. Sebbene tuttavia la modalità dell'offerta di valore sia più diretta rispetto all'architettura SOA, è meno diretta rispetto al web basato su browser, dove un sito può concretamente generare vendite o lead. Le API producono ricavi in maniera più sottile, mettendo in connessione le varie risorse delineate di seguito. Figura 2: La catena di valore delle API Sistemi backend Provider di API Sviluppatori di app App client Utenti finali 5

6 Parte 2: La catena di valore delle API Alcuni esempi di come le API generano valore Un'API ha un valore intrinseco esclusivo. In senso lato, le aziende possono utilizzarla per: Generare direttamente nuovi profitti Un'API può rivelarsi una fonte diretta di ricavi se gli sviluppatori hanno la responsabilità dell'accesso o se l'interfaccia viene utilizzata per agevolare la creazione in-house di applicazioni pay-to-play o per abilitare l'e-commerce Estendere la copertura e il valore offerto ai clienti Le API consentono di raggiungere nuovi clienti o aumentano il valore offerto ai clienti attuali offrendo servizi già esistenti tramite nuove piattaforme e device Supportare le iniziative di vendita e marketing Un'API può aiutare un'azienda a portare sul mercato i propri prodotti e servizi agevolando la creazione di quel tipo di funzionalità coinvolgenti e a tutto tondo associate alle best practice del marketing online Stimolare l'innovazione tecnica e del business Le API aiutano le aziende a sviluppare nuovi sistemi, offerte e strategie, perché riducono le barriere all'innovazione facilitando l'implementazione di idee senza modificare i sistemi backend 6

7 Parte 2: La catena di valore delle API Affrontare decisioni progettuali Le decisioni di progettazione delle API devono basarsi sulle risorse che queste devono connettere, ovvero ciò che apparirà sull'altro lato dell'interfaccia, che sia all'interno dell'infrastruttura IT aziendale che fuori dal firewall aziendale. Nello specifico, è importante rispondere alle due domande seguenti: Quali sistemi vengono esposti e dove e presso chi risiedono? Chi sono gli sviluppatori di destinazione e che tipo di applicazioni realizzeranno? Quest'ultima domanda è particolarmente importante perché fa riferimento alla principale categorizzazione delle API: private o aperte. Le API private vengono utilizzate solo all'interno dell'azienda o, in alcuni casi, dalle aziende partner. Le API aperte vengono rese disponibili a un'ampia community di sviluppatori esterni, liberi di creare le proprie app con le risorse backend dell'azienda stessa. Concettualmente le API private sono simili ai servizi web. Generalmente un'api privata ha come obiettivo quello di aiutare sviluppatori, collaboratori o partner interni a creare in modo efficiente app da utilizzare internamente o esternamente. Alla stregua dei servizi web, il risparmio sui costi rappresenta spesso l'incentivo principale, poiché le API permettono di sviluppare nuove applicazioni in modo economicamente vantaggioso. Molte API private vengono però utilizzate per creare app pubbliche, web e mobile, che generano nuovo valore di business in modo più diretto. I programmi API aperti si focalizzano sull'adozione. Consentendo a sviluppatori di terze parti di accedere alle proprie API, le aziende puntano a rendere disponibili i propri asset IT a una clientela il più vasta possibile. L'adozione da parte degli sviluppatori è un parametro chiave per valutare il successo di un'api aperta. Benché esistano meno API aperte che private, sono proprio le prime a offrire sia le più grandi opportunità di business sia i rischi e le sfide tecniche di progettazione più significative. Le API aperte propongono sfide di progettazione dell'integrazione completamente nuove (ad esempio, come aprire i sistemi backend agli sviluppatori senza esporli agli hacker), ma creano anche nuovi rischi aziendali. Un programma API aperto elaborato in modo superficiale può far sì che un'azienda cannibalizzi il proprio business core ed esponga gli asset di business critici alla concorrenza. Le decisioni di progettazione tecniche devono partire da queste considerazioni di business. La terza parte del documento illustra come allineare al meglio valutazioni di business e decisioni in ambito tecnico. 7

8 Parte 3: Allineare la progettazione API agli obiettivi di business Laddove l'architettura SOA cerca da sempre di migliorare i processi organizzativi, i programmi API puntano ad aumentare i ricavi. Pertanto le decisioni in merito alla progettazione API devono focalizzarsi chiaramente sugli obiettivi strategici di business del programma API aziendale. Prima di iniziare a progettare un'api, è bene chiarire i problemi che il programma API deve risolvere, le opportunità che mira a cogliere e in che modo. Nello specifico, è importante rispondere alle domande seguenti: Quali risorse saranno disponibili? In che modo le API devono rendere disponibili tali risorse? Quali tipi di applicazioni possono essere realizzate con l'api? In che modo gli sviluppatori possono essere motivati a utilizzare l'api? In che modo le applicazioni creano valore per il business? Comunicazione e collaborazione sono aspetti chiave della progettazione di un'api che deve affrontare queste sfide e opportunità. Nelle fasi di progettazione, implementazione e gestione di un'interfaccia, i responsabili del programma e gli architetti delle API devono collaborare strettamente per definire insieme gli obiettivi strategici, come ottenerli e come valutare i risultati del loro lavoro. Nello specifico, amministratori e tecnici devono concordare: L'obiettivo e lo stato definitivo ideale del programma Le attività iniziali che consentono all'azienda di operare per raggiungere questi obiettivi I parametri principali da utilizzare per valutare il successo Le attività quotidiane che consentiranno al programma di mantenere gli obiettivi nel tempo 8

9 Parte 3: Allineare la progettazione API agli obiettivi di business Individuare uno sponsor Per garantire che i responsabili di business e gli architetti mantengano la sintonia, il programma deve prevedere uno "sponsor" capace di colmare il divario che spesso si apre tra reparti tecnici, responsabili di business e sviluppatori di app. Le aziende compiono spesso l'errore di assegnare questo ruolo a un responsabile di marketing con poca esperienza tecnica. In realtà, questo "divulgatore delle API" deve conoscere i vincoli architetturali dell'azienda e condividere l'entusiasmo degli sviluppatori delle applicazioni. Il suo ruolo è quello di stabilire comunicazioni chiare con tutte le parti interessate e, nello specifico: Saper "vendere" il programma API a manager e altri responsabili decisionali senior Accertarsi che gli architetti delle API comprendano gli obiettivi di business dei responsabili del programma Aiutare i responsabili del programma a comprendere le risorse tecniche e i vincoli degli architetti Raccogliere informazioni sulle preferenze e i requisiti degli sviluppatori a cui è destinato il programma Figura 3: Allineare gli obiettivi delle API Dirigenti Sviluppatori di destinazione Responsabili del programma API Divulgatore API Architetto API Opportunità di profitto Obiettivi Attività Parametri Risorse tecniche Una volta stabilita la comunicazione, e concordati obiettivi, attività e parametri, può iniziare il lavoro effettivo di progettazione delle API, argomento affrontato nella quarta parte del presente documento. 9

10 Parte 3: Allineare la progettazione API agli obiettivi di business Alcune note sulla strategia di business delle API Spetta ai responsabili del programma (o "proprietari delle API") e al divulgatore delle API la responsabilità di ideare una strategia di business chiara e di comunicarla ai responsabili delle decisioni executive-level, nonché agli architetti e agli sviluppatori che si occuperanno dell'aspetto tecnico della strategia. Occorre innanzitutto definire un chiaro obiettivo di business e una visione del programma API che sia allineata con la visione olistica dell'azienda. Un'API non è una soluzione puramente tecnica e dovrebbe essere considerata come un prodotto o una strategia di business a sé stante, anche se inglobata all'interno della strategia di business aziendale complessiva. Partendo da questa considerazione, il passaggio successivo è quello di creare un modello di business intorno a questa visione, delineando i seguenti dettagli: Costi, risorse ed efficienze I sistemi, le relazioni, le attività e le altre risorse sfruttate dal programma e come il programma consente all'azienda di utilizzare al meglio tali risorse Valore, profitto e innovazione I clienti, i mercati e canali a cui è destinato il programma e come l'innovazione tecnica consentirà di generare nuovi profitti da tali obiettivi Al centro di questo modello di business deve esserci una proposta di valore che delinea chiaramente il valore di business reale e misurabile che il programma API offre all'azienda. 10

11 Parte 4: Progettazione di API fruibili Da un punto di vista prettamente tecnico, progettare un'api è semplice. Progettarne una che offra un valore reale all'azienda può però rivelarsi complicato. Oltre alle funzionalità, gli architetti aziendali devono anche considerare gli obiettivi di business e la end-user experience. Questo aspetto può essere impegnativo per chiunque intenda estendere un progetto SOA al mondo delle API. Nei progetti SOA, le esigenze degli architetti sono centrali e l'adozione da parte dell'utente viene data per scontata. Di conseguenza, gli architetti che hanno esperienza SOA possono avere un approccio alle decisioni di progettazione delle API che presuppone che l'interfaccia e gli utenti dell'applicazione abbiano esigenze e pregiudizi simili ai loro. Ciò porta quasi sempre a decisioni di progettazione sbagliate. Nelle API, il focus della progettazione non è sulla funzionalità, ma sulla user experience. La domanda principale non è quindi "Quali funzionalità è necessario esporre?" ma "In che modo gli sviluppatori utilizzeranno questa interfaccia?" Se gli sviluppatori non utilizzano l'api, questa non ha alcun valore. Pertanto, la progettazione deve incentrarsi sullo sviluppatore e prevedere le barriere più basse possibili all'accesso per il pubblico di sviluppatori di destinazione. Che l'api sia pubblicata privatamente o apertamente, una valida developer experience (DX) è fondamentale per il suo successo. La DX è nettamente più difficile da quantificare rispetto alle funzionalità esposte. Sebbene possa essere definita come la somma delle interazioni tra il provider dell'api e lo sviluppatore, il risultato di questa somma è una percezione più che un numero, cioè il sentimento degli sviluppatori nei confronti dell'interfaccia. Ovviamente si tratta di un parametro piuttosto nebuloso, ma esistono strategie che possono aiutare a capire come gli sviluppatori valuteranno i diversi approcci di progettazione dell'api. Nello specifico, è necessario: Creare profili degli sviluppatori Realizzare un prototipo dell'api e collaudarla sul campo 11

12 Parte 4: Progettazione di API fruibili Profili degli sviluppatori Non è possibile creare un'api fruibile se non si conoscono le esigenze e le preferenze degli sviluppatori a cui l'api è destinata. C'è la tendenza a presupporre che gli sviluppatori che creano le applicazioni client a partire da API siano giovani che si descrivono come hacker, ossessionati dai linguaggi e dai protocolli più recenti. Nella maggior parte dei casi in realtà, soprattutto nelle API private, gli sviluppatori di servizi aziendali sono fedeli a modalità di azione più collaudate. Per riuscire, ogni progetto API deve rivolgersi a un particolare pubblico di sviluppatori. In alcuni casi si tratta di un gruppo omogeneo con esigenze condivise, ma altri casi può essere necessario considerare una molteplicità di preferenze. È comunque necessario comprendere chi utilizzerà l'api e come definire l'interfaccia per far sì che gli sviluppatori possano utilizzare rapidamente ed efficacemente le risorse backend. Il primo passo è perciò immaginare un'identità o un insieme di identità che definiscono il tipo o i tipi di sviluppatori ai quali sono destinate le API. Di seguito le informazioni da raccogliere: Per chi lavorano, in quale reparto, e perché sviluppano un'app Competenze di programmazione, vincoli tecnici e preferenze di linguaggio/protocollo Attitudini personali e contesto nel quale lavorano meglio Creazione di un prototipo Una volta compresi gli obiettivi di lavoro, i requisiti tecnici e le preferenze personali degli sviluppatori di destinazione, è possibile iniziare a realizzare un'interfaccia che tenga conto di tali criteri. Ovviamente, è bene realizzare un prototipo più leggero e facilmente modificabile prima di creare un'api di produzione vincolata a dati reali o a sistemi backend. Il prototipo consentirà di testare i presupposti di progettazione con le identità a cui mira il progetto. Figura 4: Strumenti utili per la creazione di prototipi di API Esistono numerosi strumenti online capaci di semplificare le fasi di realizzazione e test dei prototipi di API leggeri. Tra gli esempi più diffusi: Apiary aplary.lo RAML raml.org SWAGGER swagger.io Uno strumento di progettazione che consente di realizzare rapidamente un prototipo di API senza scrivere alcun codice. Linguaggi di descrizione delle API che possono aiutare gli sviluppatori a individuare e iniziare a utilizzare l'interfaccia prototipo. Realizzare un prototipo leggero basato su dati o funzionalità usa e getta offre il vantaggio di adottare misure di sicurezza ridotte, limitando le barriere all'accesso degli sviluppatori. Ciò consente di coinvolgere gli sviluppatori di destinazione sin dalle prime fasi. Gli sviluppatori potranno scrivere app leggere per testare il progetto API e fornire un feedback. Sarà quindi possibile apportare modifiche all'interfaccia e testarla di nuovo. Dopo qualche interazione verrà quindi individuato il percorso più corretto. Tutto ciò ovviamente non ha alcuna influenza sul modo in cui vengono prese le decisioni fondamentali e reali relative alla progettazione dell'interfaccia. La quinta parte prende in esame le opzioni concrete di progettazione delle API. 12

13 Parte 5: Stili di API Scegliere uno stile di API è una delle decisioni più importanti che un designer di interfacce possa prendere. Decisioni di questo tipo partono inevitabilmente da considerazioni tecniche come la natura specifica delle risorse di backend esposte o i vincoli del reparto IT. Vanno considerati anche altri aspetti, quali gli obiettivi di business del programma API e le esigenze e le preferenze del pubblico di sviluppatori di destinazione. Tra gli stili di progettazione delle API oggi più comuni troviamo i seguenti: Web Service (Tunneling) Pragmatic REST (URI) Hypermedia (True Rest) Event-Driven (IoT) 13

14 Parte 5: Stili di API Web Service Lo stile Web Service è un approccio alla progettazione delle API indipendente dal trasporto e basato sulle operations, che utilizza il linguaggio WSLD (Web Services Description Language) per descrivere le interfacce. Deriva dal mondo SOA, nel quale le interfacce Web Service erano utilizzate per integrare reti eterogenee. È una scelta di stile da valutare se il programma prevede l'estensione di interfacce SOA. Per le API Web Service esistono grandi quantità di strumenti che semplificano e accelerano la creazione di applicazioni client. L'utilizzo di questo stile ha tuttavia seri limiti. Innanzitutto, poiché è indipendente dal trasporto, può utilizzare il protocollo HTTP che tuttavia è inefficiente in questo contesto. Non è perciò una scelta valida se si prevede l'estensione dei servizi all'open web. È inoltre pratico solo se gli sviluppatori di destinazione hanno familiarità con gli standard SOA quali WSDL, Simple Open Access Protocol (SOAP) e Remote Procedure Call (RPC). Per la maggior parte degli sviluppatori sul lato client, la curva di apprendimento è ripida, soprattutto negli scenari di API aperte e in quelle incentrate sul mobile. Di norma, gli sviluppatori di app non apprezzano il SOAP come linguaggio di programmazione e gli strumenti disponibili per realizzare client Web Service spesso non supportano il mobile. A parte le considerazioni pratiche, esiste un problema di percezione: uno stile Web Service può far apparire l'azienda "arretrata", e ridurre di conseguenza l'attrazione e l'adozione dell'api da parte degli sviluppatori di app mobile. Pragmatic REST Lo stile Pragmatic REST (Representational State Transfer) è un approccio più semplice e centrato sul web alla progettazione di interfacce di integrazione. Questo stile, che utilizza gli URI invece del linguaggio WSDL ed è specifico per il trasporto (supporta solo il protocollo HTTP), è mutuato in gran parte dallo stile Web Service. Il termine API web è utilizzato in modo interscambiabile con API RESTful e raggiungere la "RESTfulness" è spesso considerato un obiettivo chiave di qualsiasi progetto di progettazione delle interfacce. In effetti, la maggior parte delle API REST oggi in uso non soddisfa completamente i criteri REST delineati nel 2000 nella tesi di dottorato di Roy Fielding. Al contrario, il REST venne definito per descrivere in modo formale il tipo di interazioni dinamiche e con collegamenti ipertestuali che potenziano il web, mentre la maggior parte delle API web ha a che fare con lo scambio di dati statici. Per essere precisi è perciò preferibile riferirsi a questo stile di programmazione come Pragmatic REST. Capire perché lo stile Pragmatic REST ha acquisito tanta popolarità non è difficile. Poiché gli URI sono intuitivi e gli sviluppatori web e mobile hanno grande familiarità con le interfacce RESTful, l'adozione e la produttività risultano molto elevate. Inoltre, il focus sull'http rende le API Pragmatic REST perfette per lo sviluppo di moderne applicazioni web e mobile. È forse al momento lo stile più in voga per la maggior parte dei progetti. Non è tuttavia perfetto per ogni contesto, ed è probabile che gli sviluppi futuri ne metteranno in discussione l'attuale dominio. Questo stile implica alcuni compromessi: è limitato a quattro metodi, può risultare eccessivamente informale e il design degli URI non è standardizzato. L'imponente espansione di IoT e dei big data, e il contributo che dà al cambiamento del networking online porrà delle sfide a questo approccio specificamente centrato sul web. 14

15 Parte 5: Stili di API Hypermedia Lo stile di progettazione Hypermedia delle API è un approccio basato sulle attività che intende fornire un'alternativa più sostenibile allo stile Pragmatic REST. Anch'esso si incentra sugli standard URI, HTTP e RESTful ma secondo Fielding rappresenta in un certo senso un'applicazione più fedele dell'architettura RESTful, il che spiega perché il web si è dimostrato così scalabile. Da questo punto di vista, l'approccio Hypermedia è ancor più orientato al web: i collegamenti ipertestuali e i moduli del web si riflettono nel modo in cui un'api Hypermedia espone i collegamenti per la navigazione nei workflow e gli input template per la richiesta di informazioni. Proprio come Event-Driven Mentre gli stili incentrati su HTTP come Pragmatic REST e Hypermedia sono perfetti per il web e le app mobile per come noi le conosciamo, l'avvento di HTML5 e di IoT sta cambiando il panorama e apre le porte ad app più dinamiche, ma anche alla richiesta di interfacce più leggere. In questo contesto, lo stile Event-Driven, fondato sugli eventi, si pone come un'alternativa indipendente dal trasporto e pertanto ideale per abilitare le app all'uso di WebSocket e di altre alternative all'http emergenti. Questo stile si basa sugli eventi avviati da server e client e offre un'opzione a basso costo capace di offrire performance migliori negli scenari che prevedono un elevato scambio di messaggi tra backend e app. È pertanto l'architettura RESTful del web si è dimostrata altamente scalabile e capace di evolversi, un'api Hypermedia ben progettata può continuare a supportare nuove applicazioni per anni. Sebbene questo approccio architetturale sia chiaramente un'opzione interessante per le aziende che intendono creare API scalabili che supportino a lungo e in modo affidabile applicazioni web e mobile, siamo in presenza di uno stile di progettazione emergente, per il quale si segnala una notevole carenza di strumenti associati. Questo aspetto può influire sui tassi di adozione da parte degli sviluppatori e rendere la situazione più complessa per coloro che adottano l'api per creare in tempi rapidi app client potenti. ideale per IoT e per una vasta gamma di casi di utilizzo in mobilità, soprattutto messaggistica istantanea, chat video, giochi con più partecipanti e così via. È di sicuro interesse per gli sviluppatori più all'avanguardia, ma va detto che non tutti gli sviluppatori sono ossessionati dall'idea di essere sulla cresta dell'onda, e in molti casi un approccio RESTful più tradizionale può risultare più idoneo. L'HTTP è ancora il protocollo di trasporto che alimenta il web e non gestisce in modo adeguato gli eventi inviati dai client. Pertanto il modello richiesta-risposta su cui si basa questo stile può rendere più complesso lo sviluppo di app client. 15

16 Parte 5: Stili di API Figura 5: Stili architetturali per la progettazione di API Web Service Pragmatic REST Hypermedia Event-Driven Correlato a SOA Numerosi strumenti disponibili Non adatto al mobile Ideale per app web e mobile Familiare alla maggior parte degli sviluppatori di applicazioni Può non essere adattabile nel tempo Altamente orientato al web Scalabile e capace di evolversi Poco familiare agli sviluppatori Idoneo per lot e device Leggero e dinamico Non adatto a scenari standard Lo stile scelto dipende quindi dai vincoli tecnici, dagli obiettivi di business e dalle preferenze degli sviluppatori. Non bisogna cadere nella trappola di adottare uno stile alla moda, che può poi rivelarsi inadatto al contesto specifico. È invece bene scegliere uno stile che sia scalabile e adattabile nel lungo periodo, poiché le risorse cambiano, il pubblico di destinazione cresce e la natura stessa del networking online è in continua evoluzione. Indipendentemente dallo stile scelto, l'api includerà comunque determinati componenti architetturali. Nella sesta parte vengono analizzati tali componenti e la relativa organizzazione. 16

17 Parte 6: Architettura delle API Gli stili di progettazione architetturale delineati in precedenza costituiscono un modello di progettazione della struttura architetturale che abilita le funzionalità esclusive dell'implementazione dell'api. Alcuni casi d'uso richiedono l'adozione di stili di progettazione specifici. È importante anche sottolineare l'esistenza di numerosi componenti da includere nell'architettura delle API, a prescindere dallo scenario di utilizzo. Questi componenti comuni non devono essere integrati nell'implementazione di un'api ma distribuiti in un'infrastruttura API core collocata tra le API dell'azienda e le app client che le sfruttano. Astraendo questi componenti diventa più semplice e rapido progettare API aggiuntive, aggiornare una serie di API in simultanea e garantire l'esecuzione lineare di API, sistemi backend e applicazioni client. Figura 6: Livelli architetturali Applicazioni client Utenti finali Livello di sicurezza Livello di caching Per ottimizzarne l'efficacia, i componenti devono essere strutturati su più livelli, così che tutto il traffico di dati attraversi ciascuno dei livelli indicati a destra, nell'ordine specificato. Livello di rappresentazione Sistemi backend Livello di orchestrazione Implementazione di API 17

18 Parte 6: Architettura delle API Il livello di sicurezza Oltre ad aprire le porte a tante opportunità di business, le API possono potenzialmente esporre l'azienda a nuove e serie minacce alla sicurezza, poiché espongono sistemi backend e dati sensibili al mondo esterno. Le API sono vulnerabili non solo alle molte minacce che hanno flagellato il web, ma anche ad alcuni nuovi pericoli specifici. È pertanto di fondamentale importanza prevedere un modello di sicurezza specifico per le API lungo l'edge dell'architettura API. Questa esigenza di assoluta sicurezza può contrastare con uno degli obiettivi di base della progettazione, ovvero il fatto che un'api ben concepita consente agli sviluppatori di creare app che offrono un accesso senza ostacoli alle risorse aziendali, facilità di accesso che può risultare limitata dai metodi di sicurezza adottati. Per alleggerire questa limitazione, può essere utile implementare la sicurezza in un'architettura API centralizzata piuttosto che nell'implementazione dell'api e consentire l'uso di tecnologie di gestione degli accessi flessibili come OAuth e OpenID Connect. Il livello di caching L'efficienza dell'interfaccia è fondamentale per offrire a sviluppatori e utenti finali una user experience senza problemi che consente di raggiungere gli obiettivi di adozione e mantenimento del programma API. Un modo per ottimizzare l'efficienza dell'api è quello di posizionare un livello di caching nei pressi dell'edge dell'architettura API. Questo livello deve sempre consentire la delivery delle risposte nella cache per le richieste comuni, riducendo la pressione esercitata sull'effettiva implementazione dell'api e sulle risorse backend. Il livello di rappresentazione È ovvio che la presentazione dell'api deve essere quanto più developerfriendly possibile. Astraendo questo elemento dall'implementazione, è possibile concentrarsi sulla realizzazione di una modalità di accesso alle API, senza alcun impatto sulle API stesse o sulle risorse backend. Ciò semplifica la presentazione di sistemi backend complessi come interfacce web e centrate sul mobile, che gli sviluppatori possono rapidamente comprendere e sfruttare per creare app potenti e user-friendly. Il livello di orchestrazione Sebbene alcune app possano apportare maggior valore accedendo a una singola risorsa tramite una singola API, le possibilità aumentano in modo esponenziale quando si combinano i dati di più API (incluse quelle di altre aziende) e le risorse backend. Predisporre un livello di orchestrazione accanto alle stesse interfacce può consentire queste combinazioni e semplificare la procedura di composizione di nuove implementazioni a partire da più risorse backend. Il modo più efficiente per creare un'architettura API centralizzata è l'implementazione di una soluzione di API management. Nella parte successiva vengono delineati i componenti chiave dell'api management. 18

19 Parte 7: API management Costruire un'infrastruttura che centralizzi i componenti architetturali comuni di API sicure e orientate agli sviluppatori può semplificare il processo di implementazione di API che apportino valore effettivo al business. Realizzare una tale infrastruttura all'interno dell'azienda può rivelarsi tuttavia una sfida significativa. Fortunatamente oggi una serie di fornitori di software aziendale realizza soluzioni per l'api management che evitano di dover sviluppare questa infrastruttura strategica in-house. Inoltre, come il nome suggerisce, le soluzioni per l'api management includono anche funzionalità per la gestione e l'ottimizzazione delle performance delle API a lungo termine. Le soluzioni più potenti includono funzionalità per la realizzazione di un'interfaccia web tramite la quale gli sviluppatori possono individuare, raccogliere informazioni e accedere alle API, un aspetto assolutamente vitale della presentazione di un'api incentrata sugli sviluppatori che non è possibile integrare nell'implementazione stessa. 19

20 Parte 7: API management Componenti di API management Una soluzione per l'api management di livello entrerprise è costituita da due elementi chiave: Un gateway API che offre le funzionalità di sicurezza, caching e orchestrazione necessarie per implementare un'architettura API core Un portale per sviluppatori che offre un'interfaccia personalizzabile tramite la quale gli sviluppatori accedono alle API e a documentazione, forum, community e ad altri contenuti pertinenti Figura 7: Componenti di API management Sviluppatore app Portale dello sviluppatore Proprietario dell'api Architetto API Utente finale App client Gateway API Implementazione di API Sistemi backend Va sottolineato che l'api management non è semplicemente un requisito tecnico ma gioca inevitabilmente un ruolo importante nel successo di qualsiasi programma API aziendale. La gestione della composizione, delle performance e della sicurezza delle API aziendali è fondamentale per far sì che l'azienda ottenga un buon ROI dall'investimento nel proprio programma API. È inoltre vitale per coinvolgere e gestire in modo attivo gli sviluppatori e garantire che realizzino applicazioni capaci di creare valore per il business. Nella maggior parte delle aziende un'infrastruttura di API management si rivelerà essenziale per progettare, implementare e gestire API che verranno utilizzate dagli sviluppatori per creare nuove app di sicura efficacia. Scoprite i fondamenti dell'api management con l'ebook I 5 pilastri dell'api management 20

21 Conclusione Da un punto di vista architetturale, le API rappresentano un'estensione dell'architettura SOA. Proprio come l'architettura SOA crea interfacce che consentono di riutilizzare i sistemi legacy in nuovi servizi che possono espandere i confini aziendali, le API sono utilizzate per esporre le risorse backend aziendali a sviluppatori di applicazioni per device mobile e il web. Si tratta di un'estensione significativa e i requisiti di progettazione di un'api web sono probabilmente molto diversi da quelli di un servizio web SOA. Laddove i programmi SOA sono generalmente promossi dalle esigenze di risparmio sui costi IT, i programmi API puntano all'attivazione di nuovi flussi di ricavo. Un'API web connette una serie di asset di business esistenti per creare valore secondo modalità prima non previste. Una progettazione di API valida è sempre focalizzata sui risultati di business. Pertanto, le procedure di progettazione e l'architettura delle API devono essere allineate sin dall'inizio con la strategia di business dell'azienda. Gli architetti e i proprietari delle API devono predisporre un'adeguata comunicazione che garantisca l'accordo sugli obiettivi e sulle modalità per raggiungerli e misurarne il successo. Per garantire l'efficacia della comunicazione è necessaria la figura di un divulgatore delle API, capace di colmare la distanza tra ruoli aziendali e tecnici, di analizzare le esigenze dei dirigenti, dei proprietari delle API, degli sviluppatori delle applicazioni e degli architetti aziendali, per negoziare il giusto set di obiettivi, attività e parametri di valutazione. Nella pratica, progettare un'api che porti al successo aziendale significa creare un'interfaccia immediatamente utilizzabile dagli sviluppatori. Ne consegue che prima di realizzare qualsivoglia progetto, è fondamentale condurre una ricerca sistematica sul pubblico di sviluppatori, al fine di capirne l'identità e di comprendere che cosa cercano in un'api. È inoltre utile verificare le supposizioni relative alle preferenze degli sviluppatori offrendo loro prototipi di API leggere. 21

22 Conclusione Quando si è pronti a progettare l'effettiva implementazione delle API, è il momento di scegliere lo stile di progettazione che meglio si adatta al programma scelto. Le API Web Service sono adatte a programmi interni destinati a sviluppatori con esperienza SOA. Le API Pragmatic REST sono più adatte ad API aperte incentrate su device mobile e sul web. Gli stili Hypermedia e Event-Driven emergono come approcci potenzialmente più sostenibili in un futuro basato su mobile e IoT. A prescindere dallo stile, esistono alcuni elementi architetturali che vanno inclusi in qualsiasi API: sicurezza, caching, rappresentazione e orchestrazione. Per ottenere la massima efficienza e gestibilità, questi elementi non devono essere inclusi nelle singole implementazioni dell'api, ma le API nel loro complesso dovrebbero sfruttare un'architettura API centrale e su livelli collocata tra l'edge aziendale e le API stesse. Il modo più efficiente ed efficace per implementare un'architettura API centrale e garantire il successo del programma API nel lungo termine è l'adozione di una soluzione di API management. Il mercato propone diverse soluzioni, la maggior parte delle quali include due componenti comuni: Un gateway API che fornisca funzionalità di sicurezza e altre infrastrutture chiave Un portale per sviluppatori che semplifichi il coinvolgimento e la partecipazione degli sviluppatori stessi Gli odierni progetti API aziendali mettono in gioco molti elementi: grandi opportunità di business, significativi rischi di sicurezza e altro ancora. Prima di avviare la creazione di un'api è fondamentale: allineare gli obiettivi di progettazione agli obiettivi aziendali; definire le preferenze degli sviluppatori di destinazione; scegliere uno stile di implementazione adeguato; implementare un'infrastruttura di API management. Compiuti questi passi, si è pronti a realizzare API di innegabile valore. Figura 8: Prerequisiti di una buona progettazione Allineare gli obiettivi tecnici e di business Stabilire le preferenze degli sviluppatori Scegliere lo stile di progettazione dell'api Implementare un'infrastruttura API $ Soltanto CA API Management consente alle aziende di integrare sistemi, semplificare lo sviluppo di app e monetizzare i dati con il livello di sicurezza e protezione delle API oggi imprescindibile. Scoprite di più su CA API Management all'indirizzo ca.com/it/api 22

23 Informazioni su CA API Management Con oltre 300 clienti di API Management nei più svariati settori (comunicazioni, servizi finanziari, pubblica amministrazione e rivendita al dettaglio), CA Technologies offre tecnologia e know-how leader di settore, per aiutare le aziende a offrire valore tramite le API. CA Technologies offre una soluzione completa per l'api management che include un gateway ricco di caratteristiche con funzionalità di sicurezza di livello militare e un portale per sviluppatori disponibile in versione on-premise e SaaS. Scoprite di più su CA API Management all'indirizzo ca.com/it/api. API Academy Strategia, architettura e servizi di progettazione di API Di API Academy fanno parte esperti di settore convocati da CA Technologies per elaborare risorse gratuite per la community e fornire servizi di consulenza alle aziende che desiderano passare al livello successivo del proprio programma API. Per scoprire come API Academy può aiutarvi nell'elaborazione di strategia, architettura e progettazione delle API, visitate l'indirizzo apiacademy.com. CA Technologies (NASDAQ: CA) crea software che promuove l'innovazione all'interno delle aziende, consentendo loro di sfruttare le opportunità offerte dall'economia delle applicazioni. Il software rappresenta il cuore di qualsiasi business, in ogni settore. Dalla pianificazione allo sviluppo, fino alla gestione e alla sicurezza, CA Technologies lavora con le aziende di tutto il mondo per cambiare il nostro modo di vivere, interagire e comunicare, in ambienti mobile, cloud pubblici e privati, distribuiti e mainframe. Per ulteriori informazioni, visitare il sito ca.com/it. Copyright 2015 CA Technologies. Tutti i diritti riservati. Tutti i marchi, i nomi commerciali, i marchi di servizio e i logo citati nel presente documento sono di proprietà delle rispettive società. Il presente documento ha esclusivamente scopo informativo. CA Technologies declina qualsiasi responsabilità circa la completezza o la precisione delle informazioni. Nella misura consentita dalla legge applicabile, CA Technologies rende disponibile questo documento "così com'è", senza garanzie di alcun tipo, incluse, a mero titolo esemplificativo, garanzie implicite di commerciabilità, idoneità a uno scopo particolare o non violazione di diritti altrui. In nessun caso CA Technologies sarà responsabile per qualsivoglia perdita o danno, diretto o indiretto, derivante dall'utilizzo di questo documento inclusi, a titolo non esaustivo, perdita di profitti, interruzione dell'attività, perdita di avviamento o di dati, anche nel caso in cui CA Technologies fosse stata espressamente avvertita del possibile verificarsi di tali danni. CS