Definizione e storia

REST acronimo di Representational State Transfer, definisce un insieme di principi architetturali per la progettazione software. Non si riferisce pertanto ad un sistema concreto, nè si tratta di un approccio definito da un organismo di standardizzazione. La sua definizione è apparsa per la prima volta nel 2000 nella tesi “Architectural Styles and the Design of Network-based Software Architectures” di Roy Fielding. In questa tesi si analizzavano alcuni principi alla base di diverse architetture software, tra cui i principi per una architettura, che consentisse di vedere il Web come una piattaforma di elaborazione distribuita. Va precisato che i principi REST non sono necessariamente legati al Web, nel senso che si tratta di principi astratti di cui il World Wide Web risulta esserne un esempio concreto.

Negli anni 2000, questa visione del Web non ebbe l’attenzione dovuta, ma negli ultimi anni l’approccio REST ha acquisito sempre più rilevanza come metodo per la realizzazione di Web Service efficienti e scalabili ed ha al suo attivo un numero significativo di applicazioni. La ragione è semplice: Il Web ha tutto quello che serve per essere considerato una piattaforma per l’elaborazione distribuita. Secondo i principi REST, non sono necessarie altre sovrastrutture per realizzare quello che è il Web programmabile. Il che è una dichiarazione che ha posto in antagonismo i Web Service basati sul protocollo SOAP.

Principi RESTful

Come indicato nella tesi di Roy Fielding, le API sono definibili RESTful se rispettano i sei vincoli di un sistema RESTful:

  • Architettura client-server: l’architettura REST è costituita da client, server, risorse e gestisce le richieste tramite il protocollo HTTP.
  • Stateless: nessun contenuto client è archiviato nel server tra le richieste. Le informazioni relative allo stato della sessione sono invece contenute nel client.
  • Supporto cache: il caching può eliminare la necessità di alcune interazioni client-server.
  • Sistema a livelli: le interazioni client-server possono essere mediate da livelli aggiuntivi, i quali offrono altre funzionalità, quali il bilanciamento del carico, la condivisione della cache o sicurezza.
  • Codice on-demand (opzionale): i server possono ampliare la funzionalità di un client trasferendo del codice eseguibile.
  • Interfaccia uniforme: è il vincolo principale per la progettazione di API RESTful e prevede 4 aspetti:
    • Identificazione delle risorse nelle richieste: le risorse vengono identificate nelle richieste e vengono distinte dalle rappresentazioni restituite al client.
    • Manipolazione delle risorse tramite le rappresentazioni:
    • I client ricevono file che rappresentano le risorse e che devono contenere le informazioni necessarie per consentirne la modifica o l’eliminazione.
    • Messaggi autodescrittivi: ogni messaggio restituito a un client contiene le informazioni necessarie per descrivere come il client deve elaborare l’informazione.
    • Ipermedia come motore dello stato dell’applicazione: accedendo alla risorsa, il client REST deve poter individuare, attraverso hyperlink, tutte le altre azioni disponibili al momento.

Nonostante i vincoli sembrino numerosi, questi, sono molto più semplici rispetto ad altri protocolli prescritti, e ciò influisce sulla maggiore frequenza di utilizzo delle API RESTful rispetto ai metodi SOAP.

REST API: perché usarle?

L’avvento delle API risale agli albori dell’era dell’informazione, molto prima della nascita dei personal computer. A quel tempo, un’API era generalmente utilizzata come libreria per un sistema operativo. L’uso prevalente era a livello locale rispetto al sistema in cui operava, sebbene a volte passasse messaggi tra mainframe. Dopo circa 30 anni, le API sono emerse dai loro ambienti locali. Nei primi anni 2000 si trasformarono in un’importante tecnologia per l’integrazione remota dei dati.

Con il termine API (Application Programming Interface) si intende un insieme di procedure volte a portare a termine un ben preciso e determinato compito. Basti pensare che un’app può utilizzare anche 15-20 API contemporaneamente per svolgere il suo compito.

Una cosa da chiarire è che REST e RESTful non sono la stessa cosa: REST come abbiamo visto è un’architettura, mentre RESTful, come le RESTful API, sono tutto ciò che viene costruito e programmato seguendo i principi REST.

L’API REST, quindi, non è altro che un’API che segue i principi REST e che per funzionare ricorre ai comandi del protocollo HTTP, ovvero GET, POST, PATCH, PUT e DELETE.

I vantaggi dell’utilizzo delle REST API

• Indipendenza: le API Rest sono indipendenti dai linguaggi o da piattaforme specifiche. Garantiscono quindi massima libertà. E’ possibile avere un server Java, PHP, Python o Node.js.

• Separazione client-server: non è solo uno dei principi fondamentali del REST, ma rappresenta un vero e proprio vantaggio. Grazie a tale separazione, infatti, consente di trattare indipendentemente l’evoluzione delle diverse componenti, modificare solo una parte progettuale senza, per questo, essere obbligati a mettere mano sia al server che al client. L’interfaccia utilizzata, inoltre, è utilizzabile su diverse tipologie di piattaforme.

• Scalabilità: la separazione client-server si traduce in una miglior scalabilità del sistema stesso.

REST API & IES Solutions

IES Solutions sfrutta a pieno le potenzialità delle REST API, impiegandole nella implementazione di servizi di autenticazione rest con JWT, attraverso il framework Angular 7, ed in diversi progetti quali per esempio: OPENLUX, l’app per la gestione e tracciamento di imbarcazioni di lusso. Anch’io Segnalo, l’app che permette ai cittadini di inviare segnalazioni direttamente alla Sala Operativa della Protezione Civile ed in molti servizi che fanno parte di Jixel.