Get eBook - CA Technologies

Strategia e architettura delle API:
un approccio coordinato
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.
2
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.
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.
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.
Figura 1: SOA e API a confronto
$$$
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.
3
SOA
API
Obiettivo di
integrazione
Interno o verso i partner
Esterno, spesso verso
i clienti
Incentivi per
i progetti
Costi IT
Flussi di ricavi per
il business
Interfaccia con
i clienti
Architetti aziendali
Sviluppatori di app
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
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.
È 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.
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".
Figura 2: La catena di valore delle API
Sistemi backend
Provider di API
Sviluppatori di app
5
App client
Utenti finali
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
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?
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.
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.
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.
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.
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
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
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
Responsabili del programma API
Sviluppatori di destinazione
Divulgatore API
Opportunità di profitto
Architetto API
Risorse tecniche
Obiettivi Attività Parametri
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
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
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.
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.
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.
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:
•
•
11
Creare profili degli sviluppatori
Realizzare un prototipo dell'API e collaudarla sul campo
Parte 4: Progettazione di API fruibili
Profili degli sviluppatori
Creazione di un prototipo
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.
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.
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.
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.
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
•
Tra gli esempi
più diffusi:
1
2
3
Apiary
aplary.lo
Uno strumento di progettazione che
consente di realizzare rapidamente
un prototipo di API senza scrivere
alcun codice.
RAML
raml.org
Linguaggi di descrizione delle API
che possono aiutare gli sviluppatori
a individuare e iniziare a utilizzare
l'interfaccia prototipo.
SWAGGER
swagger.io
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.
Attitudini personali e contesto nel quale lavorano meglio
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
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)
13
Event-Driven
(IoT)
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.
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.
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
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.
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.
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.
14
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.
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.
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.
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.
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
15
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
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.
Figura 6: Livelli architetturali
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.
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.
Applicazioni
client
Livello di sicurezza
Utenti finali
Livello di
caching
Livello di
rappresentazione
Livello di
orchestrazione
17
Sistemi
backend
Implementazione
di API
Parte 6: Architettura delle API
Il livello di sicurezza
Il livello di rappresentazione
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.
È 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.
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 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 livello di caching
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.
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.
18
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
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
Utente finale
Sviluppatore app
Portale dello sviluppatore
Proprietario dell'API
Architetto API
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
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.
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.
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.
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
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.
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:
•
•
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.
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
Scegliere lo stile di
progettazione dell'API
Stabilire le preferenze
degli sviluppatori
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
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.
CS200-131275