Panoramica di REST. Parte 1: Cos'è REST?

CIAO! Oggi parleremo di un argomento molto interessante e, soprattutto, molto richiesto nel mercato del lavoro: il RIPOSO. Divideremo la nostra panoramica di REST in tre parti:

1. Nella prima parte tratteremo la storia di REST e descriveremo i principi su cui si basa REST.

2. Nella seconda, considereremo come avviene la comunicazione tra un client e un server tramite il protocollo HTTP.

3. Nella terza scriveremo una piccola applicazione RESTful che testeremo utilizzando un programma chiamato "Postman".

L'articolo è destinato ai lettori che hanno familiarità con i seguenti termini:

• http
• URL e URI
• JSON e (in misura minore) XML
• Iniezione di dipendenza

Parte 1. Cos'è REST?

REST, come tanto nel mondo IT, è un acronimo. Deriva da "REpresentational State Transfer" . Questo è uno stile architettonico per l'interazione tra i componenti di un sistema distribuito in una rete di computer. In poche parole, REST determina lo stile di interazione (scambio di dati) tra i diversi componenti del sistema, ciascuno dei quali può essere fisicamente collocato in luoghi diversi. Questo stile architettonico è un insieme coerente di vincoli a cui si aderisce durante la progettazione di un sistema distribuito. Questi vincoli sono talvolta chiamati i principi guida di REST. Non ce ne sono molti, solo 6. Ne parleremo poco dopo.

Storia del RIPOSO

Il termine REST è stato introdotto da Roy Fielding, uno dei creatori del protocollo HTTP, nel suo dottorato di ricerca. tesi dal titolo "Architectural Styles and the Design of Network-based Software Architectures" nel 2000. Sebbene il termine REST possa ancora essere definito giovane, il concetto che rappresenta si trova al centro stesso del World Wide Web. Non ci addentreremo in profondità nella storia del termine. Se vuoi immergerti nelle fonti primarie, dai un'occhiata alla dissertazione di Fielding .

Vincoli e principi di REST

Come affermato sopra, REST definisce come i componenti di un sistema distribuito dovrebbero interagire tra loro. In generale, ciò avviene attraverso un processo di richiesta-risposta. Il componente che invia la richiesta è chiamato client e il componente che elabora la richiesta e invia una risposta al client è chiamato server. Le richieste e le risposte vengono spesso inviate tramite il protocollo HTTP. HTTP è l'acronimo di HyperText Transfer Protocol. In genere, un server è un'applicazione web. Il cliente può essere quasi qualsiasi cosa. Ad esempio, un'app mobile che richiede dati da un 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. In questo caso, A è un client rispetto a B e B è un server rispetto ad A. Allo stesso tempo, A potrebbe elaborare le richieste di B, C, D, ecc. In questo caso, l'applicazione A è sia un server che un client. Tutto dipende dal contesto. Una cosa è certa: il componente che invia la richiesta è il client. Il componente che riceve, elabora e risponde a una richiesta è il server. Tuttavia, non tutti i sistemi i cui componenti comunicano attraverso un processo di richiesta-risposta sono sistemi RESTful. Affinché un sistema sia considerato RESTful, deve rispettare i sei vincoli REST:

1. Architettura client-server

Questo vincolo riguarda la separazione delle preoccupazioni. È necessario separare i requisiti dell'interfaccia client dai requisiti del server che memorizza i dati. Questo vincolo rende il codice client più portabile su altre piattaforme e la semplificazione lato server migliora la scalabilità del sistema. La distinzione tra "client" e "server" consente di svilupparli indipendentemente l'uno dall'altro.

2. Apolide

Un'architettura RESTful richiede che siano soddisfatte le seguenti condizioni. Nel periodo tra le richieste, il server non deve memorizzare informazioni sullo stato del client e viceversa. Tutte le richieste del client devono essere composte in modo da fornire al server tutte le informazioni necessarie per completare la richiesta. Pertanto, sia il server che il client possono "capire" qualsiasi messaggio ricevuto, senza fare affidamento sui messaggi precedenti.

3. Memorizzabile nella cache

I client possono memorizzare nella cache le risposte del server. Questi, a loro volta, devono essere designati in modo esplicito o implicito come memorizzati nella cache o non memorizzati nella cache, in modo che i client non ricevano dati obsoleti o non corretti in risposta a richieste successive. La corretta memorizzazione nella cache aiuta a eliminare completamente o parzialmente alcune interazioni client-server, aumentando ulteriormente le prestazioni e la scalabilità del sistema.

4. Interfaccia uniforme

I requisiti fondamentali di un'architettura RESTful includono un'interfaccia unificata e uniforme. Il client deve sempre comprendere il formato e gli indirizzi che deve utilizzare quando invia una richiesta e il server, a sua volta, deve anche comprendere il formato che deve utilizzare quando risponde alle richieste del client. Questa coerente interazione client-server che descrive cosa, dove, in quale forma e come inviare i dati è un'interfaccia unificata.

5. Strati

Per strati intendiamo la struttura gerarchica della rete. A volte un client può comunicare direttamente con il server e talvolta comunica solo con un nodo intermedio. L'utilizzo di server intermedi può aumentare la scalabilità grazie al bilanciamento del carico e al caching distribuito. Facciamo un esempio. Immagina un'app mobile popolare in tutto il mondo. Una parte integrante dell'app prevede il caricamento di immagini. I suoi utenti sono milioni, quindi un singolo server non può gestire un carico così pesante. Separare il sistema in strati risolverà questo problema. Se il client richiede un'immagine da un nodo intermedio, allora il nodo intermedio richiede l'immagine dal server che è meno caricata al momento e restituisce l'immagine al client. Se la memorizzazione nella cache viene applicata correttamente a ciascun livello della gerarchia,

6. Codice su richiesta (facoltativo)

Questo vincolo implica che il client può espandere la sua funzionalità scaricando il codice dal server sotto forma di applet o script.

Vantaggi di un'architettura RESTful

Le applicazioni che rispettano tutti i suddetti vincoli presentano i seguenti vantaggi: affidabilità (non è necessario salvare lo stato del client, che potrebbe andare perso)

• prestazioni (a causa dell'uso di una cache)
• scalabilità
• comunicazione trasparente
• interfacce semplici
• portabilità
• capacità di apportare facilmente modifiche
• capacità di evolvere e adattarsi alle nuove esigenze

Panoramica di REST. Parte 2: Comunicazione tra un client e un server Panoramica di REST. Parte 3: creazione di un servizio RESTful su Spring Boot