Mettere il Web nell'API Web

Obiettivi di apprendimento

Al completamento di questa unità, sarai in grado di:

• Illustrare due motivi per cui le applicazioni Web stanno diventando sempre più diffuse.
  
• Elencare gli utilizzi più comuni delle API Web.
  
• Comprendere l'economia delle API e perché la crescita delle API è stata significativa.
  

API utilizzabili in rete: una tecnologia rivoluzionaria

Le API non si limitano a interfacce utilizzabili nella stessa rete locale. Gli sviluppatori e i citizen integrator possono utilizzare anche API che vengono rese disponibili attraverso sistemi e dispositivi remoti. Può trattarsi di connessioni private, come le reti di aziende con più sedi e data center, oppure di reti pubbliche, come Internet. Gli elementi chiave di questa rete in espansione sono gli endpoint delle API.

Immagina gli endpoint come delle prese di corrente in cui le applicazioni inseriscono la spina.

Il numero e il tipo di dispositivi la cui spina può essere inserita nelle prese di corrente sono limitati unicamente dall'immaginazione di coloro che li hanno inventati e dalla capacità della rete elettrica. Analogamente, il numero di applicazioni che può sfruttare l'astrazione dei dati offerta dall'endpoint di un'API è limitato soltanto dall'immaginazione degli sviluppatori e dalla capacità dell'infrastruttura del fornitore dell'API.

Ecco un esempio: quando Google ha reso disponibile un'API per Google Maps, non è passato molto tempo prima che migliaia di sviluppatori di terze parti si facessero avanti con applicazioni uniche e innovative che la utilizzavano per incorporare le funzionalità di Google Maps direttamente nelle loro app. Pensa a Yelp, Tesla e tutte le altre applicazioni in cui vengono visualizzate mappe con il copyright di Google in un angolo.

È per questo motivo che spesso le API vengono definite come motori dell'innovazione, specialmente per i Trailblazer dell'integrazione, che considerano le API come semplici pezzi di terze parti che si possono utilizzare per ottenere risultati commerciali e creare esperienze dei clienti.

L'economia delle API

A seconda del volume di chiamate o dei risultati di altri metodi utilizzabili per suddividere un servizio su più livelli, un provider come Google può decidere di addebitare agli sviluppatori una tariffa associata all'utilizzo dell'API. Da questo nasce l'idea di Economia delle API.

Lo sviluppatore di un'applicazione deve valutare tutti i costi legati all'utilizzo dell'API rispetto a quelli che dovrebbe sostenere per sviluppare una funzionalità da zero. In alternativa, come avviene spesso nell'economia delle API, lo sviluppatore può cercare un provider più conveniente che offre un servizio simile. Ad esempio, esistono diversi concorrenti di Google Maps ben noti, tra cui Here.com.

La crescita dell'economia delle API è trainata da fornitori di servizi che entrano in competizione per soddisfare la domanda di maggiore produttività degli sviluppatori e di dati condivisi. Per ciascuno dei diversi tipi di funzionalità che possono essere richiamati mediante API (ad esempio: elaborazione delle carte di pagamento, mappe, navigazione e traduzione), esistono spesso più fornitori di API che competono per conquistare l'attenzione di sviluppatori di applicazioni e citizen integrator. Allo stesso tempo, man mano che il numero di funzionalità disponibili sotto forma di servizi basati su API aumenta, l'economia delle API accelera la tendenza verso un mondo composto di applicazioni create principalmente attraverso API pronte all'uso. Più è modulare il risultato finale, maggiore è la flessibilità con cui è possibile aggiungere nuove funzionalità attraverso altre API che alzano l'asticella in termini di funzionalità aziendali complessive.

Crescita delle API ieri e oggi

Ma se le API utilizzabili in rete sono il progresso più importante dall'invenzione del tostapane, perché l'industria tecnologica non le ha inventate prima? In realtà è andata proprio così.

Agli albori di Unix, non era raro che i programmatori richiamassero logica di business in remoto da un altro computer attraverso una rete utilizzando una tecnologia nota come RPC (Remote Procedure Call).

Che ne dici di una scorpacciata di acronimi? Con il passare del tempo, le RPC hanno ceduto il passo ad altre forme di richieste remote di dati e funzionalità, come Network DDE (Dynamic Data Exchange), CORBA (Common Object Request Broker Architecture), EDI (Electronic Data Interchange) e così via. Alla fine, è emerso il protocollo XML-RPC (guarda chi si vede: di nuovo RPC!), che col tempo si è evoluto in quello che conosciamo con il nome di servizi Web basati su XML e nel protocollo SOAP (Simple Objec Access Protocol).

Ogni volta che emergeva una nuova tecnologia per l'accesso remoto a dati o funzionalità, sembrava che si fosse realizzata l'utopia. Ma poi si sono diffuse le API Web del tipo in voga oggi, ossia API che, come abbiamo detto prima, si basano su funzionalità già integrate nel protocollo Web HTTP, attraverso l'utilizzo dei verbi speciali GET, PUT e POST. Si tratta proprio dello stesso protocollo che usiamo tutti i giorni per visitare i nostri siti Web preferiti.

Il (possibile) futuro dell'integrazione

Se la storia ci insegna qualcosa, probabilmente il metodo che utilizziamo oggi per integrare sistemi diversi potrebbe essere destinato a cambiare. Esistono due tecnologie relativamente nuove, simili alle API, che si discostano dall'approccio Web attualmente più diffuso. Una di queste, GraphQL, proviene da Facebook e l'altra, gRPC, da Google.

Entrambe presentano vantaggi rispetto alle attuali API Web. Ad esempio, GraphQL si ispira all'idea di un grafo sociale e del modo in cui diversi elementi di dati, come gli amici, le foto, i luoghi di lavoro e così via, formano labirinti di informazioni interrelate. GraphQL consente di richiedere informazioni pertinenti a un intero grafo di dati in una sola volta, a differenza dei diversi cicli di richieste che è necessario eseguire con le API tradizionali.

D'altro canto, anche gRPC presenta i suoi vantaggi. Questa tecnologia si basa su HTTP/2 (HTTP versione 2), che supporta stream di dati bidirezionali. Grazie all'utilizzo di HTTP/2, gRPC è in grado di trasformare un'API in una Streaming API, che fornisce i dati all'applicazione che la utilizza non appena questi diventano disponibili. Per determinate applicazioni, come i ticker di borsa, si tratta di un metodo per recuperare i dati molto più efficiente rispetto a quello di imporre all'applicazione di controllare costantemente se ci sono dati disponibili, come avviene con le API tradizionali.

Stessa idea, tecnologie diverse

Che si tratti del protocollo Web, GraphQL, gRPC o di qualche approccio alle API ancora da inventare, alla fine l'idea delle API utilizzabili in rete consiste nel trasformare una funzionalità aziendale in un servizio di rete che altre applicazioni possono utilizzare in remoto come una parte esternalizzata dell'esperienza cliente. Man mano che l'inventario dei pezzi esternalizzabili (l'economia delle API) cresce, crescono anche le opportunità di battere la concorrenza attraverso innovazioni ed esperienze che sarebbe difficile realizzare se si sviluppasse tutto internamente.

L'opportunità funziona anche nella direzione opposta. Di quali competenze di business l'organizzazione si deve dotare e deve mettere a disposizione degli sviluppatori esterni come servizi utilizzabili in rete sotto forma di API? È letteralmente la domanda da un milione di dollari, specialmente per coloro che vogliono diventare Trailblazer dell'integrazione.