API cosa sono e come funzionano spiegato facile

Come funzionano le API, gli agenti alla base del funzionamento delle app e servizi informatici?

Una panoramica che tocca i punti essenziali

Le API (Application Programming Interfaces) sono interfacce che permettono alle applicazioni di interagire con altre applicazioni.

Intuitivamente sono quindi alla base di una vastità di applicativi, servizi, siti web, dispositivi. Conoscerne il funzionamento è oggi importante come poteva esserlo conoscere i rudimenti di HTML negli anni ’90-’00.

Le API sono nate con la nascita stessa dell’informatica, ben prima dei personal computer. Agli albori infatti le API venivano usate come strumento di interazione tra librerie e sistemi operativi.

Negli anni ’40 gli elaboratori usavano librerie fisiche di schede perforate per gestire le diverse routine. Il primo riferimento al termine API risale al 1951. L’utilizzo invece della prima API nella concezione attuale si fa risalire al Febbraio 2000, ad opera di Salesforce.

Twitter riceve oltre 6 miliardi di chiamate API al giorno. Qualcosa come 70’000 API call al secondo.

Iniziamo con un esempio

Sono molteplici le similitudini usate per spiegare la logica dietro il funzionamento delle API (cameriere, meccanico, magazzino, biblioteca, ecc.). Quella che preferisco è quella del postino.

Il postino riceve una lettera che ha riportato un indirizzo e una modalità di consegna. Il postino esegue quindi la sua spedizione e si reca all’indirizzo indicato in busta. Qui può consegnare la lettera con successo, oppure ritornare un messaggio di mittente non trovato o indirizzo errato. Poi ritorna alla base a notificare di aver consegnato correttamente la posta o di non esserci riuscito, portando con sé altra posta, la missiva non recapitata, o altri pacchi ricevuti dal mittente.

I punti salienti di questo esempio sono:

Mittente e destinatario restano al loro posto e non vengono in contatto.
Il postino non ha necessità di conoscere il contenuto della missiva per compiere il suo lavoro.
Tutti gli attori agiscono attraverso un protocollo ben codificato e noto in anticipo; una busta non affrancata o un contenuto senza indirizzo finisce subito nella corrispondenza non recapitabile.
Per analogia, il postino è la nostra API.

Forse proprio lo stesso esempio che ha ispirato il naming di Postman, tra le API platform più usate e diffuse?

API: perché sono così importanti?

Una API è quindi un software che può essere usato da altri software per comunicare con altri software o hardware, attraverso protocolli, routine, e strumenti. Una API costituisce un agile canale di comunicazione tra dispositivi diversi.

Le API semplificano il design e l’architettura dei software, aggiungono flessibilità e sicurezza e permettono scalabilità e manutenzione nel tempo.

Le API rivestono un ruolo tanto importante oggi perché sono utilizzate da quasi la totalità dei siti e applicativi digitali e dispositivi fisici IoT. Possiamo quindi comprendere meglio gli elementi fondanti degli strumenti che usiamo ogni giorno per lavoro e svago.

Conoscere il funzionamento base delle API è utile a prescindere dal proprio ruolo lavorativo, sia per dialogare con componenti di team di sviluppo e tecnici, ma anche per sperimentare e automatizzare attività ripetitive attraverso semplici automazioni.

Secondo Gartner, entro il 2023 il 65% delle entrate dei fornitori di servizi infrastrutturali globali sarà generato tramite API. Entro il 2030, il mercato delle API e gestione delle stesse (API Management) varrà 40 miliardi di dollari secondo GlobalNews.

Come funzionano?

Abbiamo capito che le API nascono per rispondere alle esigenze di intercomunicazione tra dispositivi e applicazioni.

Siccome ogni dispositivo, programma, applicativo, viene sviluppato con linguaggi e strutture dati non omogenee tra loro e in costante evoluzione, sarebbe complesso gestire la comunicazione tra di essi a meno di non creare ogni singola volta connettori specifici.

Le API forniscono un’interfaccia di comunicazione agnostica rispetto al linguaggio di programmazione utilizzato, alle finalità dell’attività e alle specificità dell’applicativo mittente e di quello destinatario.

In una API agiscono due attori:

Server: ossia l’unità che su richiesta fornisce i dati rispondenti alla chiamata e implementa le regole di funzionamento dell’API.
Client: l’utente che effettua la chiamata (API call) per ottenere in ritorno dei dati. Il Client non ha necessità di conoscere il funzionamento del programma sottostante il Server, ma solo delle regole necessarie per implementare la chiamata.

Nel mondo reale, Server e Client possono essere applicativi web, dispositivi IoT, database, servizi front-end e back-end.

Il dialogo tra questi attori avviene attraverso un protocollo definito che il Server mette tipicamente a disposizione attraverso documentazione.

Nella documentazione sono esplicitate le tipologie di chiamate possibili, i dettagli di configurazione (es. le intestazioni o headers), i risultati attesi, il tipo di dati e informazioni che è possibile ottenere dalla chiamata all’API, o i dati che è possibile inserire in caso la trasmissione avvenga in scrittura.

Funzionamento delle API: alcuni esempi

Vediamo un semplice esempio fornito dalla API di Mailerlite, la nota piattaforma di mail automation.

Mailerlite permette di ottenere tutti gli iscritti a una newsletter con questa chiamata:

api.subscribers.all()

E tutti gli utenti che si sono disiscritti con questa chiamata alla sua API:

api.subscribers.unsubscribed()

Un approccio efficace e autoconsistente. Non si ha necessità di conoscere i dettagli implementativi del sistema. Occorre solo sapere quali siano i parametri che possono essere utilizzati per ottenere le informazioni di cui si ha bisogno.

Nel formato web, le API espongono degli endpoint sotto forma di URI (Uniform Resource Identifier).

Gli endpoint espongono l’indirizzo delle risorse che sono necessarie al funzionamento delle API stesse.

Se questa definizione può apparire astratta, è immediato comprenderne la natura con un esempio.

Questo è l’URI che Linkedin espone tra i numerosi API endpoint disponibili:

https://api.linkedin.com/v1/people/

Notiamo come la forma dell’endpoint sia auto-esplicativa, comprensibile anche senza consultare la documentazione.

Volendo spingersi ancora oltre, questo è un esempio prosaico ma estremamente comprensibile in quanto cliccabile direttamente:

https://pokeapi.co/api/v2/pokemon/ditto

Incollando questo URI nella barra del browser vedrete il JSON che ritorna tutti i dati sottostanti alla chiamata API attivata tramite l’endpoint esposto, presenti nel database che raccoglie le caratteristiche dei Pokemon.

Questi dati strutturati possono essere agilmente esposti poi in una pagina web, in una dashboard, o utilizzata per arricchire qualsiasi ulteriore applicazione.

API Documentation

È un prodotto di contenuto tecnico, contenente istruzioni su come usare e integrarsi efficacemente con un’API. È un manuale di riferimento conciso che contiene tutte le informazioni necessarie per lavorare con l’API, con dettagli su funzioni, classi, tipi di ritorno, argomenti e altro, supportato da tutorial ed esempi. La documentazione API è creata in forma testuale, spesso integrando snippet di codice che illustrano le funzioni principali. Twilio ne fornisce un ottimo esempio.

API Security

Queste prime considerazioni portano a un tema per il corretto funzionamento di un’API: la sicurezza.

Esporre infatti impropriamente dati di applicazioni può generare gravi rischi per gli utenti.

Le stesse API possono essere anelli deboli sfruttate da hacker e malintenzionati per superare le difese di un applicativo con finalità malevole.

La pervasività della tecnologia digitale rende questo scenario ancora più inquietante. Avresti mai pensato che il tuo frigo smart possa essere usato per penetrare nel tuo account Gmail?

Le azioni possibili

I criteri utilizzati per rafforzare la sicurezza di una connessione API possono essere:

Creazione di token identificativi: i token vengono generati dal Server in corrispondenza della creazione di un profilo Client, e utilizzati nella chiamata API.
Limiti alle chiamate: il numero di chiamate che ogni servizio può effettuare al Server tramite API viene limitato; questo evita sia errori di programmazione (endless loop), sia attacchi malevoli di natura Denial of Services. Evita inoltre che un solo Client monopolizzi le risorse dell’applicativo.
Utilizzo di Sniffers: analizzare il traffico e l’utilizzo del network in entrata e in uscita tramite sniffers permette di individuare comportamenti anomali e problemi.
API Gateway: un API Gateway agisce come un casello autostradale per il traffico API. Permette di controllare traffico in entrata e in uscita, informazioni diffuse e come le API vengono utilizzate.

La gestione di API collegate a grandi servizi con flussi dati rilevanti (pensiamo a servizi bancari, eCommerce, social media) richiedono uno sforzo importante anche dal punto di vista del monitoraggio e gestione operativa. Per questo non è infrequente trovare società di consulenza che offrono veri servizi di API Management per conto dei loro clienti.

Tipologie di API

Categorie di API per Release Policy

API Pubbliche

Sono servizi accessibili pubblicamente. Sono talvolta usate anche con finalità di branding per incentivare l’utilizzo della piattaforma in modo professionale e tecnico, e incentivare l’innovazione (anche) open source. Pubblico non significa però gratuito, un’API Pubblica può richiedere comunque il versamento di un corrispettivo quando ha finalità commerciali.

API Private

Sono servizi utilizzati solo all’interno dell’azienda per il funzionamento specifico dell’applicativo e funzioni accessorie. Alla base della logica dei microservizi.

API Partner

Sono API usate tra partner aziendali, ad esempio per fornire servizi di pagamento, tracciatura di attività, servizi, integrazione software.

Categorie di API per Protocollo e Specifiche

Remote Procedure Call (RPC)

Protocollo nato per specificare le interazioni tra applicazioni client-server, ossia entità esistenti su network, computer o periferiche diverse tra loro. Il protocollo RPC permette agli utenti di lavorare con procedure remote come se le procedure fossero locali. Le chiamate a procedure remote sono definite attraverso routine contenute nel protocollo RPC. Ad ogni messaggio di chiamata corrisponde un messaggio di risposta. Le API RPC invocano tipicamente azioni o processi eseguibili. RPC può utilizzare due diversi linguaggi, JSON e XML, per la codifica; queste API sono chiamate rispettivamente JSON-RPC e XML-RPC.

gRPC (gRPC Remote Procedure Calls)

(Sì, l’acronimo è ricorsivo come esplicitamente definito dalla documentazione). gRPC è un moderno framework open source ad alte prestazioni creato da Google nel 2015. Può essere eseguito in qualsiasi ambiente. Può connettere in modo efficiente i servizi tra i centri dati con supporto per load balancing, il tracciamento, il controllo della sicurezza e l’autenticazione. gRPC è usato principalmente per la comunicazione tra microservizi anche grazie alle sue elevate performance.

Simple Object Access Protocol (SOAP)

SOAP è un protocollo definito “leggero” basato su XML per lo scambio di informazioni in un ambiente distribuito. SOAP permette l’implementazione di RPC in modo standard. É stato disegnato da Microsoft nel 1998, poi arricchito da IBM e Lotus. Le API progettate con il protocollo SOAP trasmettono le richieste mediante HTTP o SMTP. SOAP è stato progettato per essere indipendente da qualsiasi modello di programmazione particolare e da altre semantiche specifiche dell’implementazione dei servizi che ne fanno uso.

Representational State Transfer (REST)

Introdotto nel 2000 da Roy Fielding in una celebre dissertazione (Architectural Styles and the Design of Network-based Software Architectures). A differenza di SOAP, REST non è un protocollo ma uno stile architetturale del software, che nasce volutamente per un pubblico esteso di utilizzatori. Le API REST utilizzano richieste (o metodi) HTTP per dialogare con le risorse (GET, POST, PUT, HEAD, DELETE, PATCH, OPTIONS).

Architettura RESTful

L’approccio architetturale REST è definito da sei vincoli:

Client-Server Architecture: l’architettura è composta da Client e Server, che comunicano tra loro tramite protocollo HTTP. Le parti agiscono in modo tra loro indipendente (ad esempio il Client non deve occuparsi del salvataggio delle informazioni, che rimangono nei singoli Server).
Stateless: nessun contenuto Client è archiviato nel Server. Ciascuna richiesta dai vari Client contiene tutte le informazioni necessarie per richiedere il servizio.
Cacheable: il Client può mettere in cache (memoria a rapido utilizzo ma scarsa capienza) informazioni avute dal Server per ottimizzare e velocizzare la trasmissione di dati.
Layered: le interazioni Client-Server possono essere mediate da livelli aggiuntivi per migliorare prestazioni, sicurezza, autenticazione ecc. anche senza che ciò sia esplicitato verso il Client.
Code on-demand (opzionale): i Server possono temporaneamente estendere o personalizzare le funzionalità del Client trasferendo del codice eseguibile.
Uniform Interface: interfaccia di comunicazione omogenea tra Client e Server per renderne più agevole modifica e disaccoppiamento anche in singoli blocchi. Questo è il vincolo più rilevante per la progettazione di API RESTful e prevede a sua volta quattro aspetti principali:
- Identificazione delle risorse nelle richieste.
- Manipolazione delle risorse tramite rappresentazioni.
- Messaggi autodescrittivi.
- Ipermedia come motore dello stato dell’applicazione (Hypermedia as the Engine of Application State – HATEOAS): un punto cardine dell’architettura REST. Con HATEOAS, un cliente interagisce con un’applicazione di rete i cui server applicativi forniscono informazioni in modo dinamico attraverso gli ipermedia. Detto altrimenti, il Client non ha bisogno di una pregressa conoscenza a riguardo delle possibili interazioni con il Server. Ciò avviene in modo dinamico attraverso hyperlink e metadati.

Quando un’architettura rispetta tutti questi vincoli, viene definita RESTful.

I sistemi RESTful supportano la messaggistica in diversi formati, come testo semplice, HTML, YAML, XML e JSON.

GraphQL

Creato da Facebook nel 2012 per scopi interni e pubblicamente rilasciato nel 2015 è diventato in breve un nuovo standard. GraphQL è un linguaggio Open Source di interrogazione e manipolazione dei dati.

GraphQL prevede:

Uno schema strongly-typed: data una query, gli strumenti possono assicurare che la query sia sintatticamente corretta e valida prima dell’esecuzione e il server può garantire sulla forma e la natura della risposta.
Un utilizzo sensibile all’ottimizzazione delle risorse: il Client modifica la query in base ai dati che realmente necessita aumentando performance e consumo di banda.
Flessibilità: il Client in autonomia modula la richiesta sui campi che necessita senza bisogno che venga creato un nuovo endpoint API.

É tipicamente utilizzato per dispositivi mobili e IoT (grazie a un uso più efficiente della banda), applicazioni dove informazioni nidificate devono essere recuperate in via unitaria (in una singola call), ad esempio Social Media e Blog (post, commenti, like, condivisioni). Inoltre trova applicazioni nell’utilizzo delle Data Platform (dove si necessita di recuperare dati da diverse fonti).

Per approfondire la genesi di GraphQL, consiglio questo bel documentario che illustra i momenti salienti raccontati dai protagonisti.

I formati dati più comuni

XML (eXtensible Markup Language)

É un linguaggio di markup flessibile ampiamente usato per lo scambio di informazioni all’interno di network. XML è leggibile sia da computer che da umani con relativa semplicità, grazie a tag autodescrittivi. Il linguaggio di markup è un insieme di simboli che possono essere inseriti nel testo per delineare ed etichettare le parti del documento di testo.

I documenti di testo XML contengono tag autodescrittivi di oggetti di dati, il che li rende facilmente leggibili, come osservabile dall’esempio che segue:

<?xml version="1.0" encoding="UTF-8"?>
<utenti>
    <utente anni="65">
        <nome>Guglielmo</nome>
        <cognome>Cancelli</cognome>
        <indirizzo>Redmond</indirizzo>
    </utente>
    <utente anni="50">
        <nome>Elone</nome>
        <cognome>Muschio</cognome>
        <indirizzo>CapeTown</indirizzo>
    </utente>
</utenti>

JSON (JavaScript Object Notation)

É un formato di interscambio dati basato sul linguaggio JavaScript (ECMA-262 1999). Ogni file JSON contiene collezioni di coppie nome/valore e liste ordinate di valori. Poiché queste sono strutture di dati universali, il formato può essere utilizzato con qualsiasi linguaggio di programmazione.

{
	"name": "Steve",
	"surname": "Jobs",
	"active": false,
	"favoriteFood": "apple",
	"birthday": {
		"day": 24,
		"month": 2,
		"year": 1955  },
	"languages": [ "us", "en" ]
}

I vantaggi

Dopo questa lunga cavalcata nel mondo delle API possiamo senza ombra di dubbio affermare che esse siano strumenti importantissimi per la creazione di applicativi che siano:

Collaborativi: grazie alla facilità di interfaccia tra team di sviluppatori e tra applicativi stessi.
Scalabili: in quanto consentono di utilizzare servizi sviluppati in precedenza attraverso una logica a blocchi (SOA-Service Oriented Application e microservizi).
Trasparenti: in quanto consentono una comunicazione codificata tra utenti e sistemi.
Profittevoli: in quanto le stesse API possono costituire un elemento di redditività di un applicativo.
Mantenibili: in quanto le modifiche ai software e sistemi possono avvenire senza impatto sulla filiera a patto che il comportamento delle API sia rispettato.
Sicuri: in quanto grazie alle API l’azienda mantiene controllo su accessi ai propri prodotti e risorse.

API: casi curiosi di utilizzo

E per finire un po’ di relax con una carrellata di API curiose da testare e provare.

PokéAPI: l’API RESTful per scoprire tutti i Pokemon e le loro caratteristiche.

SWAPI: l’API di Star Wars, completa con veicoli e equipaggiamenti di tutti e sette i film.

Product Hunt: per restare aggiornati su tutte le novità tecnologiche e gadget in arrivo su PH. In questo caso con interfaccia GraphQL.

Chomp: un’API REST per scoprire i valori nutrizionali di oltre 875’000 prodotti da supermarket.

International Space Station: vuoi sapere dove si trova esattamente l’ISS? Ecco il servizio che fa per te.

Football API: amante del calcio? Qui le statistiche relative a oltre 860 coppe e leghe calcistiche.

Chuck Norris: un’API pubblica riguardante fatti e barzellette su Chuck Norris.

E l’elenco potrebbe continuare ancora a lungo.

Abbiamo quindi appurato che gli utilizzi per le API sono molteplici, creativi, a portata di mano, e anche possibili casi di business.

E adesso?

Ti è stata utile questa lettura? Hai delle osservazioni, o ti fa piacere approfondire ulteriormente l’argomento? Scrivici!

Passa dalla teoria alla pratica con i nostri tutorial passo-passo:

E resta aggiornato sulle nuove tecnologie con i nostri approfondimenti:

Bibliografia

Url verificati a Dicembre 2022.

API cosa sono e come funzionano

Come funzionano le API, gli agenti alla base del funzionamento delle app e servizi informatici?