Architettura REST, le Pratiche di buona Progettazione

Architettura REST, le Pratiche di buona Progettazione

architettura RESTPrima 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

 

 

Ti potrebbe interessare anche…

Commenti

1 commento

  1. dome

    I principi architetturali in caso non vengano rispettati cosa succede ? il servizio non e più considerato rest ?
    o se li segue tutti viene considerato restful ?

    Rispondi

Rispondi a dome Annulla risposta

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Cos’è AddLance?

AddLance è un servizio gratuito che ti permette di trovare l’aiuto che cerchi. Hai bisogno di un logo, di un sito web, di testi, traduzioni, consulenze legali o altro? Su AddLance ottieni gratis i contatti dei migliori professionisti italiani.

Iscriviti alla Newsletter

Share This