Servizi web orientati sulla base dell’architettura REST

Il World Wide Web consta di molte più componenti rispetto a quelle che un utente percepisce al momento della visualizzazione di un sito o di un’applicazione. Così per esempio accedono ai dati e ai contenuti di diversi siti non solo utenti umani ma anche robot, che si fingono degli utenti. Il requisito è che il rispettivo gestore renda il suo sito accessibile ad altre applicazioni, mettendo a disposizione un relativo servizio web. Un buon esempio è Twitter: grazie a un relativo servizio web qualsiasi applicazione può scegliere o addirittura scrivere tweet a nome di un utente di twitter.

Per implementare questo tipo di servizio web, ci sono diverse tecniche come la chiamata di procedura remota (RPC), il protocollo di rete SOAP o anche l’architettura software Representational State Transfer (REST), di cui parliamo in questo articolo.

Il concetto di REST deriva da una dissertazione del 2000 di Roy Fielding, uno dei più importanti sviluppatori di protocolli web. Fielding descrive in forma astratta l’architettura alla base del World Wide Web (il protocollo HTTP, i parser HTML e XML, le applicazioni web e quelle server). Fondamentalmente l’architettura REST non dipende da protocolli specifici. La sua caratteristica principale risiede in risorse che devono essere soddisfatte secondo i seguenti requisiti di Fielding:

• Indirizzabilità: ogni risorsa, per esempio una prenotazione, un prodotto o un articolo, deve poter essere identificata tramite un Unique Resource Identifier (URI).

• Interfaccia unica: deve essere possibile accedere a ogni risorsa in modo semplice e unitario con l’aiuto di metodi standard. Per esempio metodi HTTP come GET, POST o PUT.

• Struttura client-server: in generale vale il principio client-server, secondo il quale un server mette a disposizione un servizio, che se necessario può essere richiesto da un client.

• Assenza di stato: la comunicazione tra server e client non presenta alcuno stato. Questo significa che tutti i messaggi scambiati contengono tutte le informazioni necessarie per poterli leggere. Il server non memorizza informazioni aggiuntive tra i due messaggi come per esempio sotto forma di sessioni. L’assenza di uno stato rende i servizi REST altamente scalabili, in quanto le richieste in entrata possono essere distribuite facilmente ai diversi server tramite bilanciamento del carico. 

• Diverse rappresentazioni delle risorse: ogni risorsa può avere diverse forme di visualizzazione. In base a cosa il client richieda, deve poter essere consegnato in diversi linguaggi o formati come HTML, JSON o XML.

• Hypermedia: la messa a disposizione delle risorse avviene tramite hypermedia, per esempio sotto forma di attributi “href”- e “src” nei documenti HTML o tramite elementi JSON e XML, definiti per le rispettive interfacce. Di conseguenza il client usa un’API REST esclusivamente tramite URL, secondo il principio “Hypermedia as the Engine of Application State (HATEOAS)”, che il server mette a disposizione, senza aver bisogno di alcuna nozione aggiuntiva sull’interfaccia.

Questi requisiti rigorosi dell’architettura REST consentono lo sviluppo di servizi ben strutturati, che sono semplici da integrare e comunicano tramite un protocollo unitario HTTP. Grazie alla struttura orientata sulla base di risorse nell’idea di un servizio web REST rientra anche la ricerca di protocolli specifici per applicazioni, necessaria per alternative di questo tipo come SOAP.

Per realizzare un servizio REST vengono utilizzati il protocollo HTTP e la relativa versione crittografata HTTPS. Questo va ricondotto da una parte all’enorme diffusione, grazie alla quale è abilitato in quasi ogni firewall; dall’altra il protocollo HTTP senza stato consente la definizione di un protocollo molto semplice, senza che vengano fornite implementazioni specifiche. Inoltre lo standard HTTP definisce già un intero set di comandi con cui si può accedere alle risorse:

La lista di comandi può essere estesa grazie all’implementazione di altri protocolli, come per esempio il protocollo WebDAV che aggiunge i metodi COPY (copiare le risorse), MOVE (spostare le risorse), LOCK (bloccare le risorse), UNLOCK (sbloccare le risorse) e MKCOL (creare una directory).

Soprattutto i metodi standard GET, POST, PUT/PATCH e DELETE sono utilizzati nello sviluppo di un servizio REST tramite HTTP, cosa che fa ritenere come l’architettura sia adatta solo per la gestione di dati semplici. Anche il principio di assenza di stato delle risorse REST sembra limitare molto le possibilità dell’architettura. Se le risorse vengono utilizzate nel modo giusto, l’interfaccia REST permette tuttavia molto più del semplice inserimento di dati, come dimostrano i seguenti esempi:

• Servizi web per elaborare le transazioni: per realizzare servizi web per effettuare le transazioni è fondamentale un gestore di transazioni (in inglese Transaction Manager). Poiché tutte le risorse a causa dell’assenza di stato vengono memorizzate sempre senza informazioni aggiuntive tra due richieste, cioè senza l’assegnazione di sessioni, l’attuazione del REST è limitata a due opzioni:

1. le risorse vengono configurate in modo tale che le transazioni possano essere elaborate nell’ambito di una richiesta.
2. Viene creata una risorsa, che gestisce le domande di transazioni. Ogni richiesta fatta a questo gestore di risorse crea automaticamente un’altra risorsa che viene identificata tramite un URI e rappresentata tramite una transazione collegata. Le modifiche possono essere successivamente memorizzate sul server come rappresentazioni di questa risorsa. Un’altra richiesta al gestore di transazioni chiude la transazione.

• Servizi web asincroni: per determinati servizi web è auspicabile che richiesta e risposta siano disgiunte nel tempo. Poiché l’HTTP non offre alcun processo automatico per questo caso, rimane solo l’opzione di gestire autonomamente le elaborazioni di richieste in qualità di fornitore di servizi e di inoltrarle sulla base di richieste specifiche degli utenti.

• Servizi web con una vasta interoperabilità: i servizi REST sono caratterizzati da una grande flessibilità che deriva da una parte dalla concentrazione su un unico protocollo di base, dall’altra dall’indirizzamento diretto delle singole risorse. Soprattutto i client Mobile approfittano dei pochi requisiti richiesti dall’architettura REST. La facile accessibilità delle risorse ha anche l’effetto che queste possano essere trovate facilmente dai motori di ricerca.

La struttura REST offre mezzi eccellenti per la realizzazione e la creazione di servizi web dei più diversi tipi. Grazie al fatto che quasi tutti i dispositivi supportano l’HTTP sia i client desktop sia quelli Mobile possono lavorare facilmente e senza ulteriori implementazioni con l’interfaccia REST. Il risultato sono servizi web che vengono particolarmente apprezzati per un alto grado di:

• Indipendenza dalla piattaforma

• Scalabilità

• Performance

• Interoperabilità

• Flessibilità.

Il suo utilizzo richiede tuttavia competenze adeguate, anche perché soprattutto l’interazione tra le singole risorse senza status è molto difficile e complessa da realizzare. Chi ha già lavorato con alternative come il protocollo SOAP, sarà costretto a rivisitare il suo bagaglio di conoscenze a riguardo a causa di un approccio totalmente diverso e insolito. Alla fine si potrà guadagnare però un servizio utilizzabile molto più facilmente nei contesti più inaspettati.