REST è l’acronimo di REpresentational State Transfer. È uno stile architettonico per sistemi ipermediali distribuiti ed è stato presentato per la prima volta da Roy Fielding nel 2000 nella sua famosa tesi.

Come qualsiasi altro stile architettonico, anche REST ha i suoi 6 vincoli guida che devono essere soddisfatti se un’interfaccia deve essere definita RESTful. Questi principi sono elencati di seguito.,

Principi guida di REST

1. Client–server – Separando i problemi dell’interfaccia utente dai problemi di archiviazione dei dati, miglioriamo la portabilità dell’interfaccia utente su più piattaforme e miglioriamo la scalabilità semplificando i componenti del server.
2. Stateless-Ogni richiesta dal client al server deve contenere tutte le informazioni necessarie per comprendere la richiesta e non può sfruttare alcun contesto memorizzato sul server. Lo stato della sessione viene quindi mantenuto interamente sul client.,
3. Cacheable – I vincoli della cache richiedono che i dati all’interno di una risposta a una richiesta siano implicitamente o esplicitamente etichettati come cacheable o non cacheable. Se una risposta è memorizzabile nella cache, a una cache client viene dato il diritto di riutilizzare i dati di risposta per richieste successive e equivalenti.
4. Uniform interface-Applicando il principio di ingegneria del software di generalità per l’interfaccia componente, l’architettura complessiva del sistema è semplificata e la visibilità delle interazioni è migliorata., Per ottenere un’interfaccia uniforme, sono necessari più vincoli architettonici per guidare il comportamento dei componenti. REST è definito da quattro vincoli di interfaccia: identificazione delle risorse; manipolazione delle risorse attraverso rappresentazioni; messaggi auto-descrittivi; e, ipermedia come motore dello stato dell’applicazione.
5. Sistema a strati – Lo stile del sistema a strati consente a un’architettura di essere composta da livelli gerarchici vincolando il comportamento dei componenti in modo tale che ogni componente non possa “vedere” oltre il livello immediato con cui interagiscono.,
6. Code on demand (opzionale) – REST consente di estendere la funzionalità client scaricando ed eseguendo codice sotto forma di applet o script. Ciò semplifica i client riducendo il numero di funzionalità necessarie per essere pre-implementate.

Risorsa

L’astrazione chiave delle informazioni in REST è una risorsa. Qualsiasi informazione che può essere nominata può essere una risorsa: un documento o un’immagine, un servizio temporale, una raccolta di altre risorse, un oggetto non virtuale (ad esempio una persona) e così via., REST utilizza un identificatore di risorsa per identificare la particolare risorsa coinvolta in un’interazione tra componenti.

Lo stato della risorsa in un particolare timestamp è noto come rappresentazione delle risorse. Una rappresentazione è costituita da dati, metadati che descrivono i dati e collegamenti ipermediali che possono aiutare i client nella transizione allo stato desiderato successivo.

Il formato dei dati di una rappresentazione è noto come tipo di supporto. Il tipo di supporto identifica una specifica che definisce il modo in cui una rappresentazione deve essere elaborata. Un’API veramente RESTful sembra ipertesto., Ogni unità indirizzabile di informazioni porta un indirizzo, esplicitamente (ad esempio, attributi link e id) o implicitamente (ad esempio, derivato dalla definizione del tipo di supporto e dalla struttura di rappresentazione).

Secondo Roy Fielding:

Ipertesto (o ipermedia) significa la presentazione simultanea di informazioni e controlli in modo tale che l’informazione diventi l’affordance attraverso la quale l’utente (o l’automa) ottiene scelte e seleziona azioni. Ricorda che l’ipertesto non ha bisogno di essere HTML (o XML o JSON) su un browser., Le macchine possono seguire i collegamenti quando comprendono il formato dei dati e i tipi di relazione.

Inoltre, le rappresentazioni delle risorse devono essere auto-descrittive: il client non ha bisogno di sapere se una risorsa è dipendente o dispositivo. Dovrebbe agire sulla base del tipo di media associato alla risorsa. Quindi, in pratica, finirai per creare molti tipi di media personalizzati, normalmente un tipo di media associato a una risorsa.

Ogni tipo di supporto definisce un modello di elaborazione predefinito., Ad esempio, HTML definisce un processo di rendering per l’ipertesto e il comportamento del browser attorno a ciascun elemento. Non ha alcuna relazione con i metodi di risorsa GET / PUT/POST/ DELETE / other a parte il fatto che alcuni elementi del tipo di supporto definiranno un modello di processo che va come “elementi di ancoraggio con un attributo href creano un collegamento ipertestuale che, quando selezionato, richiama una richiesta di recupero (GET) sull’URI corrispondente all’attributo href codificato CDATA.,”

Metodi di risorse

Un’altra cosa importante associata a REST sono i metodi di risorse da utilizzare per eseguire la transizione desiderata. Un gran numero di persone collega erroneamente i metodi delle risorse ai metodi HTTP GET/PUT/POST/DELETE.

Roy Fielding non ha mai menzionato alcuna raccomandazione su quale metodo utilizzare in quale condizione. Tutto ciò che sottolinea è che dovrebbe essere un’interfaccia uniforme. Se decidi che HTTP POST verrà utilizzato per aggiornare una risorsa, piuttosto che la maggior parte delle persone consiglia HTTP PUT, va bene e l’interfaccia dell’applicazione sarà riposante.,

Idealmente, tutto ciò che è necessario per modificare lo stato della risorsa deve essere parte della risposta API per quella risorsa, inclusi i metodi e in quale stato lasceranno la rappresentazione.

Un’API REST deve essere inserita senza alcuna conoscenza preliminare oltre all’URI iniziale (segnalibro) e all’insieme di tipi di supporti standardizzati appropriati per il pubblico previsto (ad esempio, che dovrebbe essere compreso da qualsiasi client che potrebbe utilizzare l’API)., Da quel momento in poi, tutte le transizioni di stato dell’applicazione devono essere guidate dalla selezione client di scelte fornite dal server presenti nelle rappresentazioni ricevute o implicite dalla manipolazione da parte dell’utente di tali rappresentazioni. Le transizioni possono essere determinate (o limitate) dalla conoscenza del cliente dei tipi di media e dei meccanismi di comunicazione delle risorse, entrambi i quali possono essere migliorati al volo (ad esempio, code-on-demand).,

Un’altra cosa che ti aiuterà durante la creazione di API RESTful è che i risultati delle API basate su query dovrebbero essere rappresentati da un elenco di collegamenti con informazioni di riepilogo, non da array di rappresentazioni di risorse originali perché la query non sostituisce l’identificazione delle risorse.

REST e HTTP non sono uguali !!

Molte persone preferiscono confrontare HTTP con REST. REST e HTTP non sono uguali.

REST !,= HTTP

Tuttavia, poiché REST intende anche rendere il web (Internet) più snello e standard, sostiene l’uso più rigoroso dei principi REST. Ed è da qui che le persone cercano di iniziare a confrontare REST con web (HTTP). Roy fielding, nella sua tesi, non ha menzionato alcuna direttiva di implementazione, inclusa qualsiasi preferenza di protocollo e HTTP. Fino al momento, stai onorando i 6 principi guida di REST, puoi chiamare la tua interfaccia RESTful.,

In parole più semplici, nello stile architettonico REST, i dati e le funzionalità sono considerati risorse e sono accessibili utilizzando URI (Uniform Resource Identifier). Le risorse vengono gestite utilizzando una serie di operazioni semplici e ben definite. I client e i server si scambiano rappresentazioni di risorse utilizzando un’interfaccia e un protocollo standardizzati, in genere HTTP.

Le risorse sono disaccoppiate dalla loro rappresentazione in modo che il loro contenuto sia accessibile in una varietà di formati, come HTML, XML, testo normale, PDF, JPEG, JSON e altri., I metadati relativi alla risorsa sono disponibili e utilizzati, ad esempio, per controllare il caching, rilevare errori di trasmissione, negoziare il formato di rappresentazione appropriato ed eseguire l’autenticazione o il controllo degli accessi. E, soprattutto, ogni interazione con una risorsa è apolide.

Tutti questi principi aiutano le applicazioni RESTful ad essere semplici, leggere e veloci.