Servizi web orientati sulla base dell’ar­chi­tet­tu­ra REST

Il World Wide Web consta di molte più com­po­nen­ti rispetto a quelle che un utente per­ce­pi­sce al momento della vi­sua­liz­za­zio­ne di un sito o di un’ap­pli­ca­zio­ne. 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 ri­spet­ti­vo gestore renda il suo sito ac­ces­si­bi­le ad altre ap­pli­ca­zio­ni, mettendo a di­spo­si­zio­ne un relativo servizio web. Un buon esempio è Twitter: grazie a un relativo servizio web qualsiasi ap­pli­ca­zio­ne può scegliere o ad­di­rit­tu­ra scrivere tweet a nome di un utente di twitter.

Per im­ple­men­ta­re questo tipo di servizio web, ci sono diverse tecniche come la chiamata di procedura remota (RPC), il pro­to­col­lo di rete SOAP o anche l’ar­chi­tet­tu­ra software Re­pre­sen­ta­tio­nal State Transfer (REST), di cui parliamo in questo articolo.

Il concetto di REST deriva da una dis­ser­ta­zio­ne del 2000 di Roy Fielding, uno dei più im­por­tan­ti svi­lup­pa­to­ri di pro­to­col­li web. Fielding descrive in forma astratta l’ar­chi­tet­tu­ra alla base del World Wide Web (il pro­to­col­lo HTTP, i parser HTML e XML, le ap­pli­ca­zio­ni web e quelle server). Fon­da­men­tal­men­te l’ar­chi­tet­tu­ra REST non dipende da pro­to­col­li specifici. La sua ca­rat­te­ri­sti­ca prin­ci­pa­le risiede in risorse che devono essere sod­di­sfat­te secondo i seguenti requisiti di Fielding:

• In­di­riz­za­bi­li­tà: ogni risorsa, per esempio una pre­no­ta­zio­ne, un prodotto o un articolo, deve poter essere iden­ti­fi­ca­ta tramite un Unique Resource Iden­ti­fier (URI).

• In­ter­fac­cia 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 di­spo­si­zio­ne un servizio, che se ne­ces­sa­rio può essere richiesto da un client.

• Assenza di stato: la co­mu­ni­ca­zio­ne tra server e client non presenta alcuno stato. Questo significa che tutti i messaggi scambiati con­ten­go­no tutte le in­for­ma­zio­ni ne­ces­sa­rie per poterli leggere. Il server non memorizza in­for­ma­zio­ni ag­giun­ti­ve 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 di­stri­bui­te fa­cil­men­te ai diversi server tramite bi­lan­cia­men­to del carico. 

• Diverse rap­pre­sen­ta­zio­ni delle risorse: ogni risorsa può avere diverse forme di vi­sua­liz­za­zio­ne. In base a cosa il client richieda, deve poter essere con­se­gna­to in diversi linguaggi o formati come HTML, JSON o XML.

• Hy­per­me­dia: la messa a di­spo­si­zio­ne delle risorse avviene tramite hy­per­me­dia, per esempio sotto forma di attributi “href”- e “src” nei documenti HTML o tramite elementi JSON e XML, definiti per le ri­spet­ti­ve in­ter­fac­ce. Di con­se­guen­za il client usa un’API REST esclu­si­va­men­te tramite URL, secondo il principio “Hy­per­me­dia as the Engine of Ap­pli­ca­tion State (HATEOAS)”, che il server mette a di­spo­si­zio­ne, senza aver bisogno di alcuna nozione ag­giun­ti­va sull’in­ter­fac­cia.

Questi requisiti rigorosi dell’ar­chi­tet­tu­ra REST con­sen­to­no lo sviluppo di servizi ben strut­tu­ra­ti, che sono semplici da integrare e co­mu­ni­ca­no tramite un pro­to­col­lo unitario HTTP. Grazie alla struttura orientata sulla base di risorse nell’idea di un servizio web REST rientra anche la ricerca di pro­to­col­li specifici per ap­pli­ca­zio­ni, ne­ces­sa­ria per al­ter­na­ti­ve di questo tipo come SOAP.

Per rea­liz­za­re un servizio REST vengono uti­liz­za­ti il pro­to­col­lo HTTP e la relativa versione crit­to­gra­fa­ta HTTPS. Questo va ri­con­dot­to da una parte all’enorme dif­fu­sio­ne, grazie alla quale è abilitato in quasi ogni firewall; dall’altra il pro­to­col­lo HTTP senza stato consente la de­fi­ni­zio­ne di un pro­to­col­lo molto semplice, senza che vengano fornite im­ple­men­ta­zio­ni spe­ci­fi­che. 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’im­ple­men­ta­zio­ne di altri pro­to­col­li, come per esempio il pro­to­col­lo 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).

So­prat­tut­to i metodi standard GET, POST, PUT/PATCH e DELETE sono uti­liz­za­ti nello sviluppo di un servizio REST tramite HTTP, cosa che fa ritenere come l’ar­chi­tet­tu­ra sia adatta solo per la gestione di dati semplici. Anche il principio di assenza di stato delle risorse REST sembra limitare molto le pos­si­bi­li­tà dell’ar­chi­tet­tu­ra. Se le risorse vengono uti­liz­za­te nel modo giusto, l’in­ter­fac­cia REST permette tuttavia molto più del semplice in­se­ri­men­to di dati, come di­mo­stra­no i seguenti esempi:

• Servizi web per elaborare le tran­sa­zio­ni: per rea­liz­za­re servizi web per ef­fet­tua­re le tran­sa­zio­ni è fon­da­men­ta­le un gestore di tran­sa­zio­ni (in inglese Tran­sac­tion Manager). Poiché tutte le risorse a causa dell’assenza di stato vengono me­mo­riz­za­te sempre senza in­for­ma­zio­ni ag­giun­ti­ve tra due richieste, cioè senza l’as­se­gna­zio­ne di sessioni, l’at­tua­zio­ne del REST è limitata a due opzioni:

1. le risorse vengono con­fi­gu­ra­te in modo tale che le tran­sa­zio­ni possano essere elaborate nell’ambito di una richiesta.
2. Viene creata una risorsa, che gestisce le domande di tran­sa­zio­ni. Ogni richiesta fatta a questo gestore di risorse crea au­to­ma­ti­ca­men­te un’altra risorsa che viene iden­ti­fi­ca­ta tramite un URI e rap­pre­sen­ta­ta tramite una tran­sa­zio­ne collegata. Le modifiche possono essere suc­ces­si­va­men­te me­mo­riz­za­te sul server come rap­pre­sen­ta­zio­ni di questa risorsa. Un’altra richiesta al gestore di tran­sa­zio­ni chiude la tran­sa­zio­ne.

• Servizi web asincroni: per de­ter­mi­na­ti servizi web è au­spi­ca­bi­le che richiesta e risposta siano disgiunte nel tempo. Poiché l’HTTP non offre alcun processo au­to­ma­ti­co per questo caso, rimane solo l’opzione di gestire au­to­no­ma­men­te le ela­bo­ra­zio­ni di richieste in qualità di fornitore di servizi e di inol­trar­le sulla base di richieste spe­ci­fi­che degli utenti.

• Servizi web con una vasta in­te­ro­pe­ra­bi­li­tà: i servizi REST sono ca­rat­te­riz­za­ti da una grande fles­si­bi­li­tà che deriva da una parte dalla con­cen­tra­zio­ne su un unico pro­to­col­lo di base, dall’altra dall’in­di­riz­za­men­to diretto delle singole risorse. So­prat­tut­to i client Mobile ap­pro­fit­ta­no dei pochi requisiti richiesti dall’ar­chi­tet­tu­ra REST. La facile ac­ces­si­bi­li­tà delle risorse ha anche l’effetto che queste possano essere trovate fa­cil­men­te dai motori di ricerca.

La struttura REST offre mezzi ec­cel­len­ti per la rea­liz­za­zio­ne e la creazione di servizi web dei più diversi tipi. Grazie al fatto che quasi tutti i di­spo­si­ti­vi sup­por­ta­no l’HTTP sia i client desktop sia quelli Mobile possono lavorare fa­cil­men­te e senza ulteriori im­ple­men­ta­zio­ni con l’in­ter­fac­cia REST. Il risultato sono servizi web che vengono par­ti­co­lar­men­te ap­prez­za­ti per un alto grado di:

• In­di­pen­den­za dalla piat­ta­for­ma

• Sca­la­bi­li­tà

• Per­for­man­ce

• In­te­ro­pe­ra­bi­li­tà

• Fles­si­bi­li­tà.

Il suo utilizzo richiede tuttavia com­pe­ten­ze adeguate, anche perché so­prat­tut­to l’in­te­ra­zio­ne tra le singole risorse senza status è molto difficile e complessa da rea­liz­za­re. Chi ha già lavorato con al­ter­na­ti­ve come il pro­to­col­lo SOAP, sarà costretto a ri­vi­si­ta­re il suo bagaglio di co­no­scen­ze a riguardo a causa di un approccio to­tal­men­te diverso e insolito. Alla fine si potrà gua­da­gna­re però un servizio uti­liz­za­bi­le molto più fa­cil­men­te nei contesti più ina­spet­ta­ti.