Il Representational State Transfer, meglio conosciuto nella sua abbreviazione REST, è annoverato tra i paradigmi di programmazione più importanti dello sviluppo web contemporaneo. Il tipo di architettura, presentato da Roy Fielding nel 2000 nella propria dissertazione ha come primo scopo quello di adattare in modo ottimale le applicazioni web alle esigenze attuali del web.
Dato che REST nel passato più recente ha guadagnato popolarità e importanza, molti operatori di progetti web cercano di aggiornare il concetto nel migliore dei modi. I risultati di questi sforzi tuttavia spesso non sono realmente “RESTful” o “conformi a REST”, poiché alcuni principi e caratteristiche (come HATEOAS) non sono stati adeguatamente implementati.
HATEOAS è un acronimo che sta per “Hypermedia as the engine of application state” (hypermedia come motore dello stato dell’applicazione). Questo concetto, introdotto da Fielding nell’ambito della sua definizione REST, descrive una delle proprietà decisive di REST: poiché l’architettura deve offrire un’interfaccia universale, HATEOAS richiede che il client REST possa spostarsi solo attraverso l’applicazione web seguendo gli URI (Uniform Resource Identifier) in formato ipermediale. Se questo principio viene implementato, il client necessita soltanto di una comprensione di base degli ipermedia per poter interagire con l’applicazione o il server.
La preparazione di singoli URI avviene come nell’esempio:
Con l’implementazione del principio HATEOAS, l’interfaccia di un servizio REST si può adattare in qualunque momento, vantaggio importante di questa architettura se comparata ad altre strutture di applicazioni, per esempio a quelle che funzionano sulla base di SOAP (Simple Object Acces Protocol).
Per mettere a fuoco HATEOAS e il suo significato per REST, occorre dare uno sguardo al costrutto generale. Fielding descrive cinque principi generali da soddisfare per ottenere un service che sia conforme a REST.
Per tutelare la vostra privacy il video si caricherà dopo aver cliccato.
In ogni caso deve esserci una struttura client server che consente anche una comunicazione stateless tra client e server (ogni richiesta viene quindi trattata senza riferimento a richieste precedenti). Inoltre il servizio deve essere costruito a più strati e utilizzare i vantaggi di HTTP caching, per rendere l’utilizzo del servizio per il client il più semplice possibile. Infine è obbligatorio realizzare la summenzionata implementazione di un’interfaccia uniforme.
Per il collegamento tra server e client, Fielding prescrive i seguenti requisiti:
HATEOAS è quindi una delle caratteristiche elementari dei REST API e perciò indispensabile per qualsiasi servizio REST.
Troverete maggiori informazioni su REST nel nostro articolo sul tema.
Per rendere il concetto di HATEOAS più accessibile, l’implementazione verrà illustrata utilizzando l’esempio di un negozio online. Come tipico delle pubblicità sul web, HATEOAS è realizzato tramite collegamenti ipertestuali. Questi rimandi tra due documenti o i rimandi ad altri punti del documento stesso vengono indicati in HTML come segue:
<a href="URI">Link-Text</a>I media collegati in questo modo, come ad esempio testo, grafica, audio e video, vengono denominati Hypermedia. Le applicazioni web riguardano soprattutto semplici documenti di testo in formato HTML, che si possono vedere anche come “stati” (inglese: “states”) di questa applicazione. Nell’ambito della filosofia REST i documenti singoli sono sempre indirizzabili tramite un URI univoco. Applicando questo concetto ad un normale negozio web, il risultato è il seguente:
Il documento che descrive lo stato “Carrello” ha un URI specifico (ad esempio 'https://example.org/carrello'). Allo stesso modo ci sono anche degli URI per i singoli articoli che vengono immessi nel carrello (come ad esempio 'https://example.org/articolo/1', 'https://example.org/articolo/2' etc). Un altro possibile stato è l’account del cliente, a cui si può accedere direttamente dal carrello e che potrebbe avere il seguente URI: 'https://example.org/cliente/1'. Ogni singolo documento contiene inoltre rinvii o collegamenti ipertestuali ad azioni che l’utente potrebbe eseguire successivamente.
Per rimanere nello scenario prospettato, questo significa che il documento del carrello contiene anche rimandi agli URI degli articoli e dei clienti, i quali potrebbero a loro volta contenere altri rimandi ai produttori o a documenti contrattuali. Tramite la GET request il client si muove nel negozio o in questo caso nel carrello grazie ai diversi collegamenti ipertestuali, come mostra il seguente diagramma semplificato:
Con un REST service nel quale il principio di HATEOAS viene applicato come prospettato da Fielding, lo user deve solamente conoscere l’URI di partenza per approfittare dell’offerta come pianificato dallo sviluppatore.
La possibile comunicazione tra client e server si può spiegare sulla base della struttura del negozio web precedentemente illustrata. Così l’applicazione client fa la seguente request per ottenere una rappresentazione XML dello stato del carrello:
GET example.org/cart HTTP/1.1
Host: example.org
Accept: application/xml
La risposta del server assomiglierà alla seguente:
HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: 256
<!--?xml version="1.0"?-->
<cart></cart>
<cart_number>1</cart_number>
<link rel="account" href="https://example.org/customer/1">
<link rel="article" href="https://example.org/article/1">
<link rel="article2" href="https://example.org/article/2">
La collaborazione tra diversi sistemi di applicazione è diventata sempre più importante nel corso degli ultimi anni, soprattutto per via del numero crescente di dispositivi mobili. Per rispondere a questa tendenza, vengono sviluppati numerosi servizi web che consentono il trasferimento di dati tra diversi sistemi. Il REST, un paradigma formulato già nell’anno 2000, gode di una sempre maggiore...
I database NoSQL sono ormai diventati delle valide alternative ai classici sistemi di database relazionali, come MySQL, e sostituiscono la struttura fissa di memorizzazione tradizionale con un procedimento flessibile. In questo modo le banche dati si possono distribuire facilmente su più server per garantire un’alta disponibilità delle applicazioni web. Ma questi sistemi, come MongoDB, hanno...
Con le architetture microservice si è affermato un modello relativamente nuovo per la strutturazione di complesse applicazioni. Invece di affidarsi a un codice sorgente che finisce con l’assomigliare a un unico infinito codice di programmazione, si costruisce il programma sviluppando servizi a sé stanti. Legata a questo modello c’è anche una ristrutturazione dei processi di lavoro, che favorisce...
Le applicazioni web hanno bisogno di interfacce per poter scambiare dati. Per lavorare a un progetto web garantendo anche ad altri programmi l’accesso per la determinazione di serie di dati, non si può fare a meno di un’API (Application Programming Interface). Solitamente gli sviluppatori attingono a realtà consolidate come REST o SOAP; GraphQL, tuttavia, ci dimostra che esiste una valida...
Grazie alla Continuous Delivery gli sviluppatori di software automatizzano il processo di sviluppo, controllo qualità, test, produzione e rilascio. Per farlo, consegnano al cliente il prodotto ancora a un primo stadio di sviluppo, mentre continuano a lavorare al programma. Il presupposto è l’utilizzo di una pipeline di Continuous Delivery suddivisa in diverse fasi di test. Ma quali sono i vantaggi...
Offri ai tuoi clienti servizi professionali e affidabili con l'hosting di IONOS.
Scopri i pacchetti
Dominio omaggio per un anno