Probabilmente avrai già sentito parlare di Web Service e di API e tutto ciò tipicamente coniugato con l’acronimo REST. L’argomento è articolato ed un po’ di chiarezza non guasterebbe ma per fortuna questo articolo nasce appositamente. Ti farò un quadro della situazione, partendo dalle esigenze scatenanti e vedremo a che punto siamo con queste importanti tecnologie.
I Web Service o servizi web sono delle funzionalità esposte da un server che permettono di essere invocate da programmi esterni via rete e a seguito di elaborazione restituiscono un risultato. Una definizione simile può fornire un’idea del concetto, ma risulta al contempo piuttosto vaga. Ti potresti porre in questo momento le seguenti domande: di che tipo di funzionalità si tratta? Di che tipo sono questi programmi esterni? Come si dialoga attraverso le reti? Sono domande assolutamente lecite ma non abbiamo voluto essere vaghi appositamente, è proprio la natura di questi servizi web che li rende adattabili a qualsiasi scopo ed in una infinità di modi. Rispondiamo alle domande una per una.
Di che tipo di funzionalità si tratta?
Ogni server gestisce un certo insieme di informazioni, a seconda del motivo per cui è stato creato. Se si tratta di un server su cui è in esecuzione un sito di e-commerce conterrà articoli in vendita, prezzi, dati di clienti, aziende fornitrici, etc. Se si tratta di un network di informazioni conterrà notizie mentre se ospita un servizio chat avrà al suo interno messaggi, username, riferimenti personali e via dicendo. Chi gestisce servizi di questo tipo può decidere se e quali informazioni offrire pubblicamente. Ad esempio, un sito di e-commerce potrebbe decidere di offrire pubblicamente elenchi di prodotti in vendita, il relativo prezzario, statistiche sui prodotti più trattati ma non dati personali di utenti o lo storico dei loro acquisti. Potranno essere così pubblicate funzionalità che metteranno a disposizione di applicazioni esterne solo i dati che si vorranno condividere, tutto ciò fattibile praticamente con qualsiasi tecnologia (tra le più comuni per Web Service: Javascript con Node.js, PHP, Java, Python. L’accesso ai servizi web può essere gratuito o a pagamento, a seconda delle intenzioni di chi gestisce il server che pubblica le funzionalità.
Di che tipo sono i programmi esterni che accedono ai Web Service?
Per lo più, al giorno d’oggi, web app (pagine web che grazie a jQuery e altre tecnologie Javascript interagiscono con servizi web) e applicazioni mobile come app Android o app iOS. Oltre a ciò può trattarsi di qualsiasi programma informatico con o senza interfaccia utente.
Come si dialoga attraverso le reti?
Affinchè un server che offre i servizi web ed un client (web app, app mobile o qualsiasi altro programma) possano dialogare ci deve essere reciproco accordo sul protocollo di comunicazione da utilizzare e sui formati dei dati. Per quanto riguarda il primo, i servizi web si poggiano su quello che è il vettore principale della Rete ossia HTTP, il protocollo su cui tutto il sistema WWW si basa e che ha visto negli ultimi anni anche la nascita della sua versione evoluta, HTTP/2. I formati di comunicazione sono per lo più XML e soprattutto JSON, ormai diffusissimo in ogni tipo di impiego pratico. Le applicazioni esterne che accederanno al servizio potranno essere prodotte dai suoi stessi gestori per offrire qualcosa in più agli utenti (esempio immediato: pensiamo ai possessori di un sito che realizzano la loro app mobile) oppure da entità esterne, le cosiddette “terze parti”, che sfrutteranno i dati di un servizio web per realizzare un proprio prodotto: ad esempio, se più compagnie aeree tramite i loro servizi web pubblicano tutte le loro offerte last-minute, un’azienda potrebbe realizzare un’app mobile di “terze parti” per aiutare gli utenti a trovare i viaggi più scontati. Questo aspetto delle applicazioni di entità esterne non è affatto trascurabile: molte aziende sono diventate grandi proprio permettendo ad altri di usare i loro dati pubblici, in fin dei conti tutto ciò si traduce in un maggiore traffico Internet attorno al proprio servizio on line.
Le funzionalità che un servizio web offre prendono, nel loro complesso, il nome di API ossia Application Programming Interface. Molti servizi web sono stati tra gli anni ’90 e i primi 2000 realizzati con una tecnologia molto utile ma non sempre dall’approccio immediato denominata SOAP (Simple Object Access Protocol), basata su protocollo HTTP e formato XML. Il suo ruolo è stato però con il tempo ridimensionato dalla semplicità ed efficienza del modello REST, Representational State Transfer, basato su HTTP e formato JSON (anche se le API REST possono essere realizzate anche con altri formati). Proprio sulle API realizzate con REST ci soffermeremo nel resto di questo articolo.
Come tante buone idee, REST è nato in un contesto accademico. La sua culla è stata la tesi di dottorato di Roy Thomas Fielding, pubblicata nel 2000. Il suo autore è oggi considerato uno dei maggiori esperti di comunicazione in Rete, essendo tra l’altro un grande contributor del protocollo HTTP nonché cofondatore del progetto Apache HTTP Server che fa da fondamento alla maggior parte dei siti Internet esistenti.
Con REST, vengono identificate delle risorse, ossia degli aggregati di informazioni che il servizio web offre. Se ad esempio parliamo di un e-commerce che vuole rendere pubblici i prodotti in vendita e i relativi prezzi potremmo individuare come risorse il singolo prodotto, una lista di prodotti selezionati, etc. Tali risorse vengono condivise in Rete mediante protocollo HTTP e proprio qui sta l’idea geniale alla base di REST: al suo interno HTTP possiede già tutto ciò di cui uno scambio di informazioni necessita pertanto non c’è bisogno di creare alcuna ulteriore sovrastruttura. Sfruttando gli elementi interni a questo protocollo potremo instaurare un dialogo tra il client ed il server.
Il protocollo HTTP funziona mediante un modello richiesta/risposta. Un client invia una richiesta al server, il server risponde. La richiesta può includere al suo interno una serie di funzionalità. Si può chiedere solo di leggere dati, di modificarli, crearli o cancellarli. Tutto ciò viene specificato mediante un campo della richiesta HTTP detto metodo. In REST si usano per lo più quattro metodi che indicheranno quali di queste operazioni il client starà richiedendo al server: con il metodo GET si chiederà solo di leggere dei dati, con il POST di crearne di nuovi, con il PUT di modificarli e con il DELETE di cancellarli.
Ogni richiesta verrà inviata ad un particolare indirizzo web e tale URL sarà univoco per la risorsa su cui richiedere l’azione. Supponiamo che il nostro servizio abbia indirizzo web www.mioservizioweb.org/api/ e che condivida articoli ognuno contraddistinto da un numero intero (ad esempio, una chiave nel database).
Il progettista del servizio potrà decidere che:
www.mioservizioweb.org/api/prodotti/1www.mioservizioweb.org/api/offertewww.mioservizioweb.org/api/prodotti/nuovowww.mioservizioweb.org/api/prodotti/1www.mioservizioweb.org/api/prodotti/1Come si può immaginare, l’id pari a 1 è a puro titolo di esempio ma in realtà andrà impiegato qualsiasi altro valore valido nel sistema. Questi sono solo alcuni esempi ma rendono l’idea del ruolo che i metodi e gli indirizzi web hanno. Si noti ad esempio che l’indirizzo www.mioservizioweb.org/api/prodotti/1 può servire a vari scopi ma dipende da qual è il metodo che gli associamo.
Altri due punti sono da approfondire: come vengono scambiati i dati e come si determina il significato della risposta del server. Tipicamente nelle API REST i dati vengono scambiati in formato JSON, comodo da gestire in ogni linguaggio di programmazione.
Se ad esempio inviamo la POST all’indirizzo www.mioservizioweb.org/api/prodotti/nuovo i dati del nuovo prodotto saranno scritti in formato JSON ed inseriti all’interno della richiesta HTTP. Anche tutte le risposte del server saranno redatte in formato JSON ed inserite nella risposta HTTP.
Un elemento però molto importante è il cosiddetto codice di stato che consiste in un numero intero che il server inserisce nella risposta. Tale numero fornisce già da solo una forte indicazione sull’esito della richiesta. Ti è mai capitato di invocare una pagina web non esistente? Probabilmente avrai ricevuto come risposta il messaggio “404 Page not found”: ecco 404 è proprio un codice di ritorno HTTP che indica che la risorsa cercata non è disponibile.
I codici di stato sono composti da tre numeri di cui il primo indica il tenore della risposta:
se il numero inizia con 2 è buon segno, significa che la richiesta era corretta ed è stata processata con successo;
se inizia con 4 il client ha eseguito una richiesta non corretta;
se inizia con 5 si è verificato un errore non per colpa del client, ma internamente al server.
Ecco alcuni dei codici di stato più utilizzati accompagnati ognuno dal messaggio testuale ufficiale:
Iscriviti su devACADEMY e SEGUI TUTTI I CORSI che vuoi!
OLTRE 70 CORSI di coding A TUA DISPOSIZIONE con un’unica iscrizione 🙂
Così abbiamo visto tutti gli elementi principali del dialogo REST. Il client invia una chiamata ad un URL specificando un metodo (GET, POST, PUT, DELETE) e passando, se necessario, dei dati in JSON nel corpo della richiesta. Il server esegue la funzionalità collegata con l’URL e risponde inoltrando un codice di stato e, se previsto, un oggetto JSON nel corpo della richiesta.
Tutto ciò può essere fatto con qualsiasi linguaggio che comprenda HTTP quindi, in pratica, con ogni tecnologia disponibile. Il modo di attuare REST non ha bisogno di requisiti specifici, in realtà va bene un qualsiasi server e librerie apposite permetteranno di creare le funzionalità sia lato client sia server.
Oltre a ciò gli studi potranno essere approfonditi imparando, ad esempio, come gestire le fasi di autenticazione e autorizzazione di cui spesso si ha bisogno sia con servizi a pagamento sia gratuiti su cui il servizio vorrà monitorare l’utilizzo delle API o più in generale restringerne l’accesso.
Ormai i concetti sono stati chiariti e tutto è pronto: non ti resta che mettere mano alla tastiera ed iniziare ad esercitarti per diventare un grande progettista di servizi REST.
