REST è una definizione di stile architetturale applicata alle applicazioni in rete. Esiste come una serie di vincoli applicati all'implementazione dei componenti di rete, che consentono una semantica uniforme delle interfacce, piuttosto che applicazioni e sintassi specifiche.
REST come architettura di rete è stata documentata per la prima volta da Roy Fielding nella sua tesi di dottorato intitolata Architectural Styles and the Design of Network-based Software Architectures, pubblicata nel 2000. REST consente ai client di interagire con i dati memorizzati su un server, senza avere alcuna conoscenza preliminare del server o di ciò che vi è contenuto.
REST è l'acronimo di Representational State Transfer. I puristi degli acronimi lo scrivono spesso come ReST, perché la E di REST in realtà non significa nulla. IT è semplicemente la seconda lettera della parola Representational. In questo modo si evitano le controversie su come pronunciarlo, come quelle che hanno afflitto GIF negli ultimi anni. Con la E inclusa, non c'è confusione quando si pronuncia l'acronimo più preciso di RST come "polso" o anche come R-S-T.
Gli avvisi personalizzati e la visualizzazione dei dati consentono di identificare e prevenire rapidamente i problemi di salute e di prestazioni della rete.
Non esiste una definizione specifica o uno standard di cosa sia REST. Come architettura, REST definisce il modo in cui i vari componenti sono collegati tramite connettori e il modo in cui i dati vengono scambiati attraverso le interfacce. REST è una serie di vincoli o requisiti che, se rispettati, creano un'implementazione dello stile architettonico REST.
L'architettura REST non incoraggia la creazione di metodi aggiuntivi, specifici per ogni situazione. Ad esempio, un'architettura REST utilizzerebbe il metodo GET per recuperare i dati in ogni circostanza. L'unico cambiamento per i diversi tipi di dati sarebbe rappresentato da parametri diversi. Ciò è in contrasto con la creazione di un nuovo metodo per ottenere informazioni su un utente (getUser) e di un altro metodo per ottenere informazioni sui prezzi (getPricing) e così via.
L'interfaccia utente del client è separata e indipendente dalla memorizzazione dei dati sul server. Ciò consente di implementare e modificare il client indipendentemente da ciò che accade o meno sul server. Allo stesso modo, i dati sul server possono essere utilizzati e modificati indipendentemente dal modo in cui il client vi accede. Questo tipo di progettazione consente ai sistemi client e server di evolvere al proprio ritmo, indipendentemente l'uno dall'altro.
Nessun dato di sessione deve essere memorizzato sul server tra le richieste del client. In altre parole, ogni transazione deve essere in grado di comprendere completamente la richiesta senza dover accedere ad alcun contesto o dato aggiuntivo memorizzato sul server. Tutti i dati di sessione devono risiedere esclusivamente sul client.
Questo vincolo consente di semplificare il bilanciamento del carico o la tolleranza ai guasti. Un server diverso potrebbe rispondere a ogni richiesta del client e restituire gli stessi dati del server originale, purché entrambi i server abbiano gli stessi dati originali. Non è necessario passare alcun tipo di dati specifici della sessione tra questi server di bilanciamento del carico. Le sessioni che non sono stateless potrebbero dare luogo a risposte diverse se la richiesta viene elaborata da un server diverso, perché solo il server precedente avrebbe i dati specifici di quella sessione con il cliente.
In ogni Exchange, i dati devono essere contrassegnati come dati memorizzabili nella cache o non memorizzabili. I dati memorizzabili nella cache possono essere memorizzati e riutilizzati dal client. I dati non vengono cachettati sul server perché ciò violerebbe il vincolo di stateless. La possibilità di cache dei dati riduce l'aumento della larghezza di banda altrimenti necessaria per mantenere una sessione client-server stateless.
Per ottenere la piena interoperabilità, l'interfaccia è disaccoppiata dal tipo di dati, purché tutte le interazioni avvengano nello stesso modo. Quattro sotto-costrizioni assicurano l'uniformità delle interfacce: l'identificazione delle risorse, la manipolazione delle risorse attraverso le rappresentazioni, i messaggi autodescrittivi e l'Hypermedia as The Engine Of the Application State (HATEOAS).
Ogni informazione che può essere denominata è una risorsa. Una risorsa può essere una qualsiasi forma di dati. Un identificatore di risorsa è un modo per riferirsi a una risorsa specifica in un determinato momento. Tali risorse possono essere aggiornate sul server senza che il client ne sia a conoscenza in anticipo, perché ogni richiesta viene descritta e risolta in modo completo.
Una rappresentazione è lo stato attuale di una risorsa, insieme ai metadati che la accompagnano e che permettono di comprendere la rappresentazione. Il formato dei dati di una rappresentazione definisce il suo tipo di supporto. Pertanto, un client può richiedere una risorsa, ad esempio un'immagine, a un server utilizzando l'identificatore della risorsa (probabilmente un URI) e una rappresentazione dell'immagine composta dai byte che la compongono, insieme ai metadati che definiscono il formato dei dati come un tipo di supporto JPG, verrà restituita al client, che potrà quindi visualizzare l'immagine all'utente.
Ogni messaggio dal client al server deve contenere tutte le informazioni necessarie per l'elaborazione del messaggio. Nel caso della sicurezza e dell'autenticazione, il token di sicurezza deve essere scambiato in ogni messaggio.
I cookie sono molto diffusi su Internet. L'atto di controllare il cookie rispetto a tutti i dati in ogni messaggio sarebbe un esempio di messaggio non autodescrittivo e quindi non tecnicamente RESTful.
Definizione di ipermedia
L'ipermedia è simile al concetto di ipertesto o di collegamento ipertestuale, ma comprende tutte le forme di media e non solo il testo o i link. Si tratta di un modo non lineare di fornire informazioni o dati, in genere seguendo un link o un altro marcatore in una risorsa pubblicata come una pagina web. L'ipermedia può essere costituito da testo, grafica, video o altre forme di dati.
In HATEOAS, un client interagisce in rete attraverso gli ipermedia
Il client interagisce con un server utilizzando solo gli ipermedia. Questi stessi ipermedia vengono forniti dinamicamente dal server in risposta a una richiesta RESTful. Di conseguenza, non è richiesta alcuna conoscenza preliminare dei dati presenti su un server, della loro struttura o di come sono archiviati. Al contrario, è necessario utilizzare solo una struttura e dei metodi ipermediali ben definiti.
In un sistema a livelli gerarchici, nessun componente può interagire o vedere dati o interfacce se non nel proprio livello immediato. Di conseguenza, non è necessario che il client sappia come, e nemmeno se sia necessario, connettersi a qualsiasi altro server, proxy, firewall, router o endpoint. Piuttosto, qualsiasi intermediario continuerà a connettersi ai server successivi secondo i vincoli REST e la risposta risultante a qualsiasi richiesta restituita al cliente tramite gli intermediari sarà anch'essa conforme a REST. Le modifiche o le interruzioni dei sistemi intermediari sono quindi invisibili al cliente, consentendo a tali sistemi intermediari di fornire bilanciamento del carico, sicurezza o altre funzioni.
Anche se tecnicamente è indicato come opzionale, i client in un'architettura REST dovrebbero essere in grado di scaricare ed eseguire script. Ciò consente di estendere funzionalità e sistemi più complessi, pur garantendo la stessa comunicazione in stile REST tra client e server. Come per le richieste e le risposte di base, l'intera istruzione per l'esecuzione del codice scriptato deve essere indipendente e non deve richiedere una pre-implementazione sul client.
Ad esempio, un client Web può eseguire il codice JavaScript che riceve dal server. Anche se il codice risiede sul server, non viene eseguito. Invece, il codice stesso viene inviato al client come parte della richiesta e viene eseguito dal client in base alla sua implementazione. Questo è il motivo per cui la corretta implementazione degli standard nei client Web è così importante; altrimenti, lo stesso codice dal server può essere eseguito con risultati diversi su client diversi.
Notifiche in tempo reale significano una risoluzione più rapida dei problemi, in modo da poter intervenire prima che si verifichino problemi più gravi.
I componenti di un sistema REST comunicano attraverso una rappresentazione di una risorsa in uno dei diversi formati standardizzati concordati, come formati grafici, formati di documenti e vari formati web. Anche in questo caso, per essere un vero sistema REST, ogni transazione deve contenere la capacità di recuperare e interpretare la risorsa desiderata.
Una risorsa è qualsiasi cosa che possa essere nominata. La risorsa memorizzata sul server per essere richiesta dal client. Una risorsa può essere un file statico, un documento, un database, un'immagine o qualsiasi altro formato che possa essere richiesto.
Anche se oggi è un concetto comune, l'idea originale di risorsa come elemento generico, modificabile e puntuale è stata una caratteristica fondamentale di REST e del web in generale. Una risorsa è un qualsiasi dato nominabile su un server. Questi dati possono cambiare non solo in una versione più recente degli stessi dati, ma anche in un tipo di dati completamente diverso. Ciò consente di aggiornare i dati su un server in qualsiasi momento, senza che i client debbano saperlo in anticipo, una caratteristica chiave dell'interoperabilità e della disponibilità.
L'identificatore di risorsa è la posizione specifica della risorsa richiesta. Nel caso di un sistema basato su HTTP, l'identificatore di risorsa è l'URL o URI. L'identificatore di risorsa specifica una singola risorsa. Un singolo identificatore di risorsa può riferirsi a dati o risorse diverse in momenti diversi. In un sistema conforme a REST, il client non deve sapere in anticipo che tipo di risorsa sta richiedendo l'identificatore di risorsa. La risposta includerà metadati che descrivono come interpretare i dati ricevuti.
Ad esempio, anche se una richiesta URL indica /server/index.html, se la risorsa a quell'indirizzo restituisce una rappresentazione come file immagine, insieme ai metadati corrispondenti, il file immagine sarà comunque visualizzato correttamente, indipendentemente da ciò che ha detto l'identificatore della risorsa.
Si riferisce ai dati inviati al client. Come già detto, la rappresentazione deve essere uno dei formati di dati standardizzati. I dati non vengono elaborati dal server, ma interpretati dal client. Ad esempio, un client che richiede un documento HTML non riceve una grafica da visualizzare sul monitor, ma piuttosto un insieme di codice HTML che viene interpretato e visualizzato sul client. Altri esempi di rappresentazione sono i file grafici come le immagini JPEG e GIF.
I metadati di rappresentazione forniscono informazioni sulla rappresentazione al sistema. Come per la maggior parte dei metadati, i metadati di rappresentazione non fanno in genere parte di ciò che viene visualizzato dall'utente finale. I metadati della rappresentazione possono includere il tipo di supporto, la data di creazione e di modifica e il numero di versione.
I metadati delle risorse sono informazioni aggiuntive fornite al sistema sulla risorsa che esiste sul server piuttosto che sulla rappresentazione visualizzata sul client. Esempi di metadati di risorse sono i link di origine, le alternative e le informazioni sulla risorsa. Ad esempio, i metadati delle risorse possono includere testo alternativo da visualizzare nel caso in cui la rappresentazione di un'immagine non possa essere visualizzata per qualche motivo (ad esempio, il testo ALT dell'immagine in HTML).
I dati di controllo riguardano principalmente la validità della risorsa e della sua rappresentazione sul client. I dati di controllo includono se i dati sono memorizzabili nella cache o meno, nonché il tempo di scadenza assoluto, ovvero forniscono un limite alla durata di utilizzo dei dati. I dati di controllo possono anche includere una somma di controllo o altri mezzi per garantire l'integrità.
Nel suo insieme, l'architettura REST crea un framework altamente scalabile, completamente trasparente e riutilizzabile, in cui i client sono disaccoppiati dall'impianto dei servizi sui server. È indipendente dalla piattaforma, sia per il client che per il server. È indipendente dal linguaggio e dalla struttura. Non importa se i dati esistono in un database, se vengono recuperati da un processo server Java e se vengono inviati a un programma locale - come un browser - codificato in una delle diverse versioni di C.
Nel web moderno, REST è implementato utilizzando un vocabolario standard comune tra client e server noto come Hypertext Transfer Protocol, o HTTP. Tuttavia, qualsiasi implementazione conforme a tutti i principi dell'architettura REST è considerata un'implementazione RESTful. HTTP non è l'unica possibilità.
Sebbene HTTP e REST non siano la stessa cosa, HTTP nella sua forma originale è un'implementazione di REST. Ciò non sorprende se si considera che Roy Fielding stava lavorando al protocollo HTTP 1.1, mentre sviluppava l'architettura REST.
Ogni risorsa è identificata da un identificatore uniforme di risorse (URI). In genere, questo è implementato come URL all'interno di un browser web. Un URI identifica una risorsa. Non è richiesta alcuna conoscenza preliminare del sistema in cui la risorsa risiede sul server. Inoltre, l'URI (o URL) è in grado di specificare la rappresentazione di una risorsa, senza conoscere la struttura del file di tale risorsa.
In HTTP, la rappresentazione delle risorse è implementata attraverso il supporto di vari tipi di file all'interno di un browser HTTP. Pertanto, i metadati che accompagnano una risorsa definiscono uno dei diversi formati di file ampiamente supportati, come HTML, CSS, JPG, GIF e così via.
Un'implementazione RESTful pura di HTTP richiede l'uso di quattro metodi fondamentali: GET, POST, PUT e DELETE. Ciascun metodo deve essere usato esplicitamente e mappa una delle azioni fondamentali RETRIEVE DATA, CREATE RESOURCE, UPDATE RESOURCE e DELETE RESOURCE.
Alcuni metodi HTTP devono essere idempotenti. Idempotente significa che l'esecuzione dello stesso metodo con gli stessi parametri deve restituire sempre lo stesso risultato. Affinché ciò funzioni, il metodo in questione non può causare alcuna modifica sul server che possa far sì che venga restituito un risultato diverso per la stessa richiesta. In pratica, una richiesta idempotente non deve modificare i dati del server.
Utilizzati per recuperare una risorsa o informazioni sulla risorsa. Sebbene la maggior parte delle implementazioni di HTTP elaborino parametri con una richiesta GET per modificare o creare risorse, tale azione non sarebbe conforme a un'implementazione RESTful. Le richieste GET devono essere idempotenti.
Una richiesta POST crea nuovi dati su un server. Per definizione, una richiesta POST NON è idempotente. A ogni esecuzione, una richiesta POST creerebbe altri dati.
Analogamente a una richiesta POST, una richiesta PUT modifica i dati esistenti. Ad esempio, la modifica del cognome di un utente esistente. Le richieste PUT non sono intuitivamente idempotenti. Sebbene una richiesta PUT modifichi i dati, lo fa ogni volta nello stesso modo. Pertanto, l'esecuzione di una richiesta PUT che modifica il cognome di un utente produrrà sempre lo stesso risultato, purché tutti i parametri siano coerenti.
Una richiesta DELETE rimuove o cancella i dati, come suggerisce il nome. Anche le richieste di cancellazione sono idempotenti, nel senso che eseguendone una ripetutamente si otterrà sempre lo stesso stato finale, con i dati in questione non più presenti sul server. Tuttavia, per il client può sembrare che ci sia una differenza, in quanto una volta che una risorsa è stata cancellata, alla richiesta può essere risposto con un messaggio di errore, ad esempio file non trovato. Tuttavia, il metodo è ancora considerato idempotente, perché a prescindere dall'errore inviato durante la transazione, lo stato finale di tale richiesta è lo stesso della prima volta che è stata richiesta.
PRTG Network Monitor è un software di monitoraggio di rete completo e tiene traccia dell'intera infrastruttura IT.
In un post sul suo blog, ormai abbandonato, Roy Fielding ha discusso i criteri che un'API deve soddisfare per essere considerata veramente RESTful. Costruendo la sua tesi pubblicata in precedenza, questo post descriveva gli stessi concetti dell'architettura REST come dovrebbero essere applicati alle API.
Un'API RESTful è quindi quella che utilizza SOLO l'architettura REST senza la necessità di documentazione o metodi aggiuntivi rispetto a quelli che si adattano al modello. Fielding ha fornito i seguenti punti per chiarire cosa rende un'API conforme a REST.
Un'API veramente RESTful non dovrebbe dipendere da alcun protocollo e dovrebbe essere in grado di supportare qualsiasi protocollo che utilizzi URI per l'identificazione. Altrimenti, l'identificazione non è separata dall'interazione.
Una REST API non dovrebbe richiedere modifiche ai protocolli standardizzati, in particolare l'aggiunta di funzionalità extra. Quando è possibile, gli eventuali workaround richiesti devono essere definiti separatamente, con l'obiettivo di eliminarli del tutto una volta che non sono più necessari.
Uno spazio dei nomi del server deve essere indipendente dalla definizione e dai requisiti dell'API. In altre parole, l'API dovrebbe funzionare con qualsiasi server in grado di funzionare con REST, non solo con server conformi a una particolare specifica API.
