Viviamo in un mondo dove tutti sono interconnessi tra di loro, dove in pochi secondi riusciamo a mandare un messaggio ad una persona distante anche migliaia di kilometri e dove, comodamente dal letto con il nostro smartphone, potremmo anche programmare l’attivazione della macchina del caffè; ma come avviene questa connessione? Come fanno diversi dispositivi (tablet, pc, smartphone) e applicazioni a permetterlo?
Come riusciamo concretamente a fare tutte queste operazioni?
L’eroe silenzioso e poco citato che permette tutto questo sono le Application Programming Interface o meglio conosciute come API.
Ma quindi cosa sono le API?
API, come anticipato, è l’acronimo di Application Programming Interface, che tradotto significa Interfaccia per la programmazione di applicazioni. Semplificando molto, rappresentano un insieme di procedure che servono per far comunicare due o più applicazioni tra di loro.
Puoi immaginare le API come un intermediario della programmazione informatica, attraverso il quale utilizzare altri prodotti o servizi senza sapere nulla della loro implementazione.
Rifacendoci a quest’ultimo esempio, pensa a un qualsiasi linguaggio di programmazione, ad esempio JAVA o PHP, in questo caso parlando di API ci riferiamo alle loro librerie software, ossia l’insieme di funzioni o strutture dati che quel linguaggio ci mette a disposizione. Un altro esempio sono le API che permettono la comunicazione tra il mouse o la tastiera e i componenti hardware del nostro pc.
Un esempio non connesso al mondo informatico:
Immagina di andare al ristorante e di ordinare del cibo o chiedere informazioni in merito ad un piatto. Sicuramente, per fare una di queste azioni interagirai con un cameriere, rivolgendoti a lui anche per chiedere e pagare il conto oppure per altre informazioni sul menù.
Pensaci un po’.. attraverso il cameriere riusciamo a mangiare un bel piatto al ristorante, senza sapere le cose complicate che ci sono dietro la sua preparazione, come l’utilizzo dei corretti ingredienti, i tipi di piatti e padelle da utilizzare o anche la gestione delle scorte alimentari per garantire la costante preparazione dei piatti durante la giornata.
Il cameriere rappresenta l’interfaccia tra noi clienti e tutti i servizi del ristorante, quindi lui può esser visto come l’API del ristorante.
Ora hai capito perchè le API sono così utili?
Ci facilitano la vita, rendendo l’integrazione e l’utilizzo di servizi esterni molto semplice.
Che differenze ci sono con le API REST?
Per spiegare le differenze tra le API e le API REST, partiamo con un semplice assunto: non tutte le API sono REST, ma tutti i servizi REST sono API.
La parola REST, acronimo di Representational State Transfer traducibile come “trasferimento dello stato“, indica un insieme di principi architetturali definiti per la prima volta nella tesi di Roy Fielding, discussa presso l’Università della California, ad Irvine nel 2000.
L’approccio REST è basato su sei principi:
- Architettura Client-Server
- Comunicazione Stateless, in cui nessun contenuto client viene salvato sul server tra le richieste
- Caching dei contenuti per eliminare alcune interazione tra client e server
- Sistema a livelli, per supportare le interazioni tra client e server, aggiungendo ulteriori funzionalità come il bilanciamento del carico
- Interfaccia uniforme per i componenti, questo garantisce che le informazioni trasferite rispettino sempre una forma standard
- Codice on demand, questo principio è opzionale, prevede che il server restituisca del codice eseguibile al client in modo da ampliare le sue funzionalità
Ma oltre questi principi, l’elemento fondamentale dell’approccio REST sono le risorse.
Per risorsa si intende qualsiasi dato o informazione recuperabile in modo univoco.
In ambito Web il meccanismo utilizzato per recuperare le risorse è l’utilizzo di URI che si basano su chiamate HTTP.
Queste chiamate devono essere effettuate necessariamente con un verbo HTTP, come POST, GET, PUT e DELETE, ed è proprio su questi verbi che si basa il concetto che tutti conoscono come API RESTful. Ad ogni verbo è associata un operazione CRUD: create, read, update e delete.
Ora, è facile capire perché l’approccio REST si abbina tanto bene al web. Infatti, se REST indica un sistema per organizzare le interazioni tra un client e server, l’HTTP invece è il protocollo che permette l’invio concreto di questi dati.
Come già detto, questi dati o risorse sono identificate attraverso un URI specifico, ad esempio l’indirizzo che puoi vedere nella barra in alto su questo sito identifica univocamente quest’articolo.
Altri esempi sono:
- www.sito.it/blog identificherà univocamente la sezione blog di un determinato sito;
- www.sito.it/blog/articolo-1 identificherà univocamente un articolo nella sezione blog di quel sito.
In precedenza abbiamo parlato dei verbi HTTP (POST, GET, PUT e DELETE), poiché sono utilizzati anche per comunicare al server cosa fare con quella specifica risorsa! Vediamoli meglio:
METODO POST
È comunemente usato per comunicare al server il compimento di una specifica operazione, ad esempio per innescare il trigger di altri script. All’occorrenza può contenere un pacchetto di informazioni da passare al server.
Spesso viene usato da molti al posto del metodo PUT per aggiornare i dati.
METODO GET
È il metodo che il browser applica di default ad ogni nostra richiesta; per intenderci, quando navighi su un sito o clicchi su un link stai effettuando una GET verso quella risorsa.
METODO PUT
Secondo i principi REST dovrebbe essere utilizzato per creare o aggiornare un dato. Ad esempio, se chiamassimo PUT /blog/articolo-2 staremmo comunicando al server di voler creare un nuovo articolo, chiamato articolo-2.
METODO DELETE
È l’inverso della PUT, viene invocato quando si vuole cancellare una risorsa dal server.
Ci sarebbero altre informazioni importanti da dire sui metodi HTTP, ma bisognerebbe dedicare loro un articolo a parte. In questa sede ci siamo limitati a spiegare la loro connessione con i principi REST.
Ma siamo sicuri che le API che stiamo creando siano effettivamente API RESTful?
Purtroppo l’approccio REST, pur essendo uno dei più famosi e utilizzati in epoca moderna, resta uno dei più fraintesi.
REST, che, ricordiamo, significa Representational State Transfer ossia trasferimento dello stato, non ha nessuna attinenza con le operazioni che sfruttano i metodi HTTP per effettuare CRUD sul database.
Basta rileggere con attenzione i principi descritti poco più su e noterai che non è citato l’utilizzo dei metodi HTTP come avviene nei client che si considerano RESTful.
I servizi HTTP che noi creiamo o a cui accediamo nei nostri applicativi sono chiamati WEB API o anche WEB SERVICES API. Il punto su cui si concentrano non è il trasferimento dello stato, come sottolinea l’approccio REST, ma solo la gestione remota delle risorse da visualizzare, modificare o creare.
Quindi, anche se è diventato uso comune definire le nostre WEB API come servizi REST, in realtà è errato, poiché l’implementazione di un corretto approccio REST richiederebbe che il client non conosca fin da subito tutte le risorse, ma solo l’entry point delle API, ossia l’URI o LINK iniziale e che, successivamente, sia il server a gestire le transizioni di stato, inviando al client i collegamenti ipertestuali tra una risorsa e l’altra. Questo dato può essere passato anche attraverso un comune file JSON che contenga al suo interno i LINK che il cliente potrà seguire.
