Prima di parlare nel dettaglio di Architettura REST, fermiamoci un attimo sulle API. Nonostante lavori in questo campo da quasi venticinque anni, non posso evitare che la prima immagine a venirmi in mente leggendo questo termine sia quella dell’imenottero giallo e nero che svolazza in un campo di fiori colorati. Mentre API è l’acronimo di Application Programming Interface. È il modo con cui componenti software stabiliscono regole di comunicazione, un’interfaccia che consente il dialogo tra parti diverse di uno stesso software o tra parti di programmi diversi.

Le API nascono con lo scopo di permettere allo sviluppatore di usare lo stesso codice in diversi contesti.

• Ci sono API che permettono al PC di eseguire le attività richieste chiamando le varie librerie di sistema
• Ci sono le API di Facebook, Twitter, Instagram, Google dette API Oauth e utilizzate per l’autenticazione
• Ci sono le API di Ebay, Amazon e dei vari e-commerce e altre ancora.

Ma tutto questo ronzare quando è cominciato?

SOA o API? La differenza è nell’orientamento dell’architettura

All’inizio del secolo le grandi aziende cominciavano e mettere online i loro grandi DB (database) e le applicazioni. Questa tendenza si è espressa inizialmente nell’architettura orientata ai servizi (SOA), mentre più recente è stata l’evoluzione delle API orientate al web e i vari stili di disegno.

Vediamo le differenze:

• La differenza tecnica fondamentale è che l’approccio SOA si focalizza sulla creazione di servizi web che facilitano le interazioni interne, server-to-server, mentre le API web sono destinate prevalentemente alla creazione di applicazioni web e mobile, quindi all’interazione con i clienti.
• In genere i programmi SOA sono avviati 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.
• La maggior parte dei progetti SOA viene creata da e per gli architetti aziendali, per semplificare l’integrazione di sistemi eterogenei e la distribuzione di nuovi servizi IT. I programmi API hanno invece come obiettivo la soddisfazione delle esigenze degli sviluppatori, delle applicazioni e degli utenti.

Le API e l’architettura REST, un modello orientato alle risorse

Ma andiamo oltre e arriviamo all’architettura REST. REST sta per Representational State Transfer ed è uno stile nel disegno delle API. Indica la rappresentazione del trasferimento di stato di un dato qualsiasi:

• il credito residuo della tua scheda telefonica
• un’immagine
• la lista dei tuoi contatti su un social network, ecc.

Si tratta di uno stile architetturale, quindi, non di un protocollo. Qual è la differenza? Un protocollo definisce i dettagli di implementazione di un rapporto, uno stile architetturale ne delinea i requisiti. Ad esempio, uno stile architetturale può definire la regola “i client possono contattare i server, ma non il contrario”. A livello più basso nella scala di astrazione c’è il protocollo che specifica come e con che regole, il client può contattare il server, ad esempio attraverso il protocollo HTTP.

Leggi anche Web Service rest o soap, la guida per scoprirlo

Ora scendiamo dal filosofico al pratico. Il modello REST è orientato alle risorse: si applica cioè ad una risorsa che può essere un documento, un’immagine, un concetto o una persona, ma anche un’operazione o un servizio.

Ad esempio: https://www.mioecommerce.it/clienti/3 è un URI che risponde alla chiamata inviando i dati del cliente con identificativo 3. Ogni risorsa deve essere identificata in modo univoco e la URI  https://www.mioecommerce.it/clienti/3 fa proprio questo.

I 5 principi dell’architettura REST (e il 6° facoltativo)

L’architettura REST è definita in 5 principi (il sesto è facoltativo):

• Client/Server – Stabilisce il concetto di separazione delle competenze in cui il server offre una o più risorse e rimane in attesa di richieste da parte del client che vuole accedere alla risorsa. Queste richieste possono essere accettate o meno.
• Assenza di stato – Ogni richiesta deve contenere tutte le informazioni necessarie per essere elaborata, senza aver bisogno di riferimenti alle precedenti richieste. Quindi le interazioni tra client e server devono essere senza stato in modo da migliorare la scalabilità e l’affidabilità.
• Caching – Al fine di migliorare l’efficienza della rete, è possibile memorizzare il risultato di una richiesta da parte del client in modo da diminuire la latenza dei tempi di risposta.
• Stratificazione – è possibile inserire dei livelli tra client e server sotto forma di componenti intermediari, i quali trasmettono i messaggi e possono offrire ulteriori servizi (caching e sicurezza ad esempio). Ogni livello è visibile solo dal suo immediato vicino in modo da essere disaccoppiati tra loro e migliorare la flessibilità in caso di aggiornamenti. Lo svantaggio principale dei sistemi a strati è nell’aumento dei tempi di risposta.
• Interfaccia uniforme – È la proprietà che definisce l’insieme delle operazioni permesse sulle risorse e quella che contraddistingue lo stile architetturale REST da altre architetture di rete. Questo permette al client di identificare la risorsa e interagire con essa. Frequente è l’uso del protocollo HTTP tramite le operazioni come PUT, GET, POST e DELETE. Le condizioni che permettono la definizione di un’interfaccia uniforme sono:

1. individuazione delle risorse (tramite URI)
2. manipolazione delle risorse attraverso le loro rappresentazioni: una rappresentazione è un gruppo di dati (e metadati) di solito auto-descrittivo, ad es. un documento XML oppure JSON. Quando un client accede a una risorsa, non gli viene restituita la risorsa, ma piuttosto una sua rappresentazione. Inoltre, per aggiornare una risorsa, un componente può comunicare la rappresentazione desiderata della risorsa
3. messaggi autodescrittivi: ogni messaggio contiene tutte le informazioni necessarie per essere processato
4. il client deve essere responsabile del mantenimento del proprio stato e può effettuare una transizione solo attraverso hyperlinks.

• Codice su richiesta – Un client ha la possibilità di estendere le sue funzionalità attraverso il download e l’esecuzione di applet o script (cosa che avviene ad esempio quando carichiamo una pagina con js). Semplifica i client e aumenta le possibilità di estensione.

I 4 vantaggi dell’architettura REST

1. Separazione: il protocollo REST rende completamente indipendenti il client e il server. Questo permette di separare il lavoro tra chi sviluppa e quindi l’evoluzione indipendente delle diverse componenti degli sviluppi. Inoltre, è possibile sostituire il componente frontend senza modificare una riga di codice del backend e viceversa.

2. Portabilità: l’interfaccia REST utilizzata da un’applicazione web può essere riutilizzata senza nessuna modifica per lavorare con un’applicazione mobile.

3. Scalabilità: il sistema può essere scalato facilmente, ad un qualsiasi livello dell’architettura, con pochissima difficoltà e con nessun impatto per i livelli precedenti e successivi.

4. Indipendenza: L’API REST è sempre indipendente dal tipo di piattaforma e questo conferisce notevole libertà nella scelta del linguaggio o framework per l’implementazione. Un set API RESTful (per RESTful si intende un set di API che rispetta tutti i vincoli visti in precedenza) è possibile scriverlo in codice PHP, Java, Python o Node.js o qualsiasi altro. È fondamentale quindi che le risposte alle richieste avvengano sempre nel formato stabilito per lo scambio di informazioni, ad es. JSON.

L’architettura REST e suoi (ancora) ampi spazi di evoluzione

L’architettura REST è ormai una pratica abbastanza diffusa, ma nonostante la sua solidità, mantiene ampi spazi di evoluzione. Non è possibile definire uno standard di modellazione, perché ogni architetto/designer ha il suo stile. Si può fare arte anche disegnando un set di API RESTful.

Guest post a cura di Alessandro Testa