Ciao, oggi studieremo un argomento molto interessante e, soprattutto, molto richiesto nel mercato del lavoro: REST. Suddivideremo la panoramica di REST in tre parti:
Nella prima parte toccheremo la storia del REST e descriveremo i principi su cui si basa REST.
Nella seconda vedremo come avviene la comunicazione tra client e server tramite il protocollo HTTP.
Nella terza scriveremo una piccola applicazione RESTful, che testeremo utilizzando il programma Postman.
L'articolo è destinato a un lettore che abbia familiarità con i seguenti termini:
HTTP;
URL e URI;
JSON e in misura minore XML;
Iniezione di dipendenza.
Parte 1. Cos'è REST
REST, come molte cose nel mondo IT, è l'acronimo di Representational State Transfer . Questo è uno stile architettonico di interazione tra componenti del sistema distribuito in una rete di computer. In parole povere, REST definisce uno stile di interazione (scambio di dati) tra diversi componenti di un sistema, ciascuno dei quali può essere fisicamente localizzato in luoghi diversi. Questo stile architettonico rappresenta un insieme coerente di vincoli che vengono considerati quando si progetta un sistema distribuito. Queste restrizioni sono talvolta chiamate principi REST. Non ce ne sono molti, solo 6 pezzi. Ne parleremo un po' più tardi.
Applicazioni create pensando a REST, ad es. che non violano le restrizioni imposte dal REST sono detti RESTful.
Storia del RESTO
Il termine REST è stato coniato da Roy Fielding, uno dei creatori del protocollo HTTP, nella sua tesi di dottorato "Stili architettonici e progettazione di architetture software basate sulla rete" nel 2000. Possiamo dire che il termine REST è ancora giovane, sebbene il suo concetto sia alla base stessa del World Wide Web. Non approfondiremo la storia dell'origine di questo termine. Se vuoi immergerti nelle fonti originali, dai un'occhiata alla tesi di Fielding .
Restrizioni e principi REST
Come affermato sopra, REST definisce come i componenti di un sistema distribuito dovrebbero interagire tra loro. In generale, ciò avviene tramite richiesta-risposta. Il componente che invia la richiesta è chiamato client ; Il componente che elabora la richiesta e invia una risposta al client è chiamato server . Le richieste e le risposte vengono spesso inviate tramite HTTP (HyperText Transfer Protocol). In genere, un server è una sorta di applicazione web. Il cliente può non essere qualsiasi cosa, ma parecchio. Ad esempio, un'applicazione mobile che richiede dati dal server. Oppure un browser che invia richieste da una pagina web a un server per scaricare dati. L'applicazione A può richiedere dati dall'applicazione B. Quindi A è un client rispetto a B e B è un server rispetto ad A. Allo stesso tempo, A può elaborare le richieste da C, D, D, ecc. In questo caso, l'applicazione A è sia un server che un client. Tutto dipende dal contesto. Una cosa è chiara: il componente che invia la richiesta è il client. Il componente che riceve, elabora e risponde alla richiesta è il server. Tuttavia, non tutti i sistemi i cui componenti comunicano tramite richiesta-risposta sono un sistema REST (o RESTful). Affinché un sistema possa essere considerato RESTful, deve “adattarsi” a sei vincoli REST:
1. Portare l'architettura ad un modello client-server
La base di questa limitazione è la differenziazione dei bisogni. È necessario separare le esigenze dell'interfaccia client dalle esigenze del server che memorizza i dati. Questa limitazione aumenta la portabilità del codice client su altre piattaforme e la semplificazione della parte server migliora la scalabilità del sistema. La stessa distinzione tra “client” e “server” consente loro di svilupparsi indipendentemente l’uno dall’altro.
2. Mancanza di condizioni
L'architettura REST richiede che sia soddisfatta la seguente condizione. Tra una richiesta e l'altra, il server non ha bisogno di memorizzare informazioni sullo stato del client e viceversa. Tutte le richieste del client devono essere strutturate in modo che il server riceva tutte le informazioni necessarie per completare la richiesta. In questo modo sia il server che il client possono “comprendere” qualsiasi messaggio ricevuto senza fare affidamento sui messaggi precedenti.
3. Memorizzazione nella cache
I client possono memorizzare nella cache le risposte del server. Questi, a loro volta, devono essere designati esplicitamente o implicitamente come memorizzabili nella cache o non memorizzabili nella cache, in modo che i client non ricevano dati obsoleti o errati in risposta alle richieste successive. L'uso corretto della memorizzazione nella cache aiuta a eliminare alcune interazioni client-server, completamente o parzialmente, aumentando ulteriormente le prestazioni e l'estensibilità del sistema.
4. Uniformità dell'interfaccia
I requisiti fondamentali dell'architettura REST includono un'interfaccia unificata e coerente. Il client deve sempre capire in quale formato e a quali indirizzi deve inviare una richiesta, e anche il server, a sua volta, deve capire in quale formato deve rispondere alle richieste del client. Si tratta di un formato unificato per l'interazione client-server, che descrive cosa, dove, in quale forma e come inviare ed è un'interfaccia unificata
5. Strati
I livelli si riferiscono alla struttura gerarchica delle reti. A volte il client può comunicare direttamente con il server, a volte può semplicemente comunicare con un nodo intermedio. L'uso di server intermedi può aumentare la scalabilità attraverso il bilanciamento del carico e la memorizzazione nella cache distribuita. Facciamo un esempio. Immaginiamo un'applicazione mobile popolare in tutto il mondo. La sua parte integrante è il caricamento delle immagini. Dato che ci sono milioni di utenti, un server non potrebbe sopportare un carico così pesante. Dividere il sistema in strati risolverà questo problema. Il client richiederà un'immagine dal nodo intermedio, il nodo intermedio richiederà l'immagine dal server meno caricato al momento e restituirà l'immagine al client. Se la memorizzazione nella cache viene applicata correttamente a ciascun livello della gerarchia, è possibile ottenere una buona scalabilità del sistema.
6. Codice su richiesta (restrizione facoltativa)
Questa limitazione implica che il client possa espandere le proprie funzionalità scaricando codice dal server sotto forma di applet o script.
I vantaggi del RIPOSO
Le applicazioni che rispettano tutte le restrizioni di cui sopra presentano i seguenti vantaggi: affidabilità (non è necessario archiviare informazioni sullo stato del client, che potrebbero andare perse);
prestazioni (dovute all'uso della cache);
scalabilità;
trasparenza del sistema di interazione;
semplicità delle interfacce;
portabilità dei componenti;
facilità di apportare modifiche;
la capacità di evolversi, adattandosi alle nuove esigenze.
GO TO FULL VERSION