close

Trasferimento dello status di rappresentanza

Vai alla navigazione Vai alla ricerca

Il trasferimento dello stato rappresentativo o REST è uno stile di architettura software per sistemi ipermediali distribuiti come il World Wide Web . Il termine ha origine nel 2000 , in una tesi di dottorato sul web scritta da Roy Fielding , uno dei principali autori della specifica del protocollo HTTP , ed è diventato ampiamente utilizzato dalla comunità di sviluppo.

Storia

Il Web è entrato nell'uso quotidiano nel 1993-1994, quando i siti Web sono diventati disponibili per un uso generale. A quel tempo, c'era solo una descrizione frammentaria dell'architettura web e c'era pressione nel settore per concordare alcuni standard per i protocolli di interfaccia web. Ad esempio, erano state aggiunte diverse estensioni sperimentali al protocollo di comunicazione (HTTP) per supportare i proxy e venivano proposte ulteriori estensioni, ma era necessaria un'architettura web formale con cui valutare l'impatto di questi cambiamenti. [ 1 ]

Insieme, i gruppi di lavoro W3C e IETF hanno iniziato a lavorare sulla creazione di descrizioni formali dei tre principali standard Web: URI, HTTP e HTML. Roy Fielding è stato coinvolto nella creazione di questi standard (in particolare HTTP 1.0 e 1.1 e URI) e nei sei anni successivi ha sviluppato lo stile architettonico REST, testandone le restrizioni sugli standard del protocollo web e utilizzandolo come mezzo per definire l'architettura miglioramenti e per identificare le discrepanze architettoniche. Fielding ha definito REST nella sua tesi di dottorato del 2000 "Stili architettonici e progettazione di architetture software basate su rete" presso la UC Irvine.

Descrizione

Image
Roy Fielding in chat durante l'OSCON 2008

Sebbene il termine REST originariamente si riferisse a un insieme di principi architetturali, descritti di seguito, ora è utilizzato nel senso più ampio per descrivere qualsiasi interfaccia tra sistemi che utilizzi direttamente HTTP per recuperare dati o indicare l'esecuzione di operazioni sui dati, in qualsiasi formato ( XML , JSON , ecc.) senza le astrazioni aggiuntive dei protocolli basati su modelli di scambio di messaggi, come SOAP . È possibile progettare sistemi di servizi Web secondo lo stile architettonico REST di Fielding, ed è anche possibile progettare interfacce XMLHTTP secondo lo stile di chiamata di procedura remota (RPC), ma senza utilizzare SOAP. Questi due diversi usi del termine REST causano una certa confusione nelle discussioni tecniche, anche se RPC non è un esempio di REST.

REST afferma che il Web ha goduto della scalabilità come risultato di una serie di progetti fondamentali chiave:

  • Un protocollo client/server stateless : ogni messaggio HTTP contiene tutte le informazioni necessarie per comprendere la richiesta. Di conseguenza, né il client né il server devono ricordare alcuno stato delle comunicazioni tra i messaggi. Tuttavia, in pratica, molte applicazioni basate su HTTP utilizzano cookie e altri meccanismi per mantenere lo stato della sessione (alcune di queste pratiche, come la riscrittura degli URL, non sono supportate da REST)
  • Un insieme ben definito di operazioni che si applicano a tutte le risorse informative : HTTP stesso definisce un piccolo insieme di operazioni, le più importanti delle quali sono POST , GET , PUT e DELETE . Queste operazioni sono spesso identificate con le operazioni CRUD sui database (CLAB in inglese: create, read, update, delete) necessarie per la persistenza dei dati, sebbene POST non si adatti esattamente a questo schema.
  • Una sintassi universale per identificare le risorse. In un sistema REST, ogni risorsa è indirizzabile solo tramite il suo URI .
  • L' uso di hypermedia , sia per le informazioni sull'applicazione che per le transizioni di stato dell'applicazione: la rappresentazione di questo stato in un sistema REST è tipicamente HTML o XML . Di conseguenza, è possibile navigare da una risorsa REST a molte altre, semplicemente seguendo i collegamenti senza richiedere l'utilizzo di registri o altre infrastrutture aggiuntive.

Risorse

Un concetto importante in REST è l'esistenza di risorse (elementi informativi), a cui è possibile accedere utilizzando un identificatore globale ( Uniform Resource Identifier ). Per manipolare queste risorse, i componenti della rete (client e server) comunicano attraverso un'interfaccia standard (HTTP) e si scambiano rappresentazioni di queste risorse (i file che vengono scaricati e inviati) - è oggetto di dibattito, tuttavia, se il la distinzione tra le risorse e le loro rappresentazioni è troppo platonica per l'uso pratico sul web, sebbene sia popolare nella comunità di RDF .

La richiesta può essere trasmessa da un numero qualsiasi di connettori (ad esempio client, server, cache, tunnel, ecc.) ma ciascuno lo fa senza "vedere oltre" la propria richiesta (nota come stateless ) . Pertanto, un'applicazione può interagire con una risorsa conoscendo l'identificatore della risorsa e l'azione richiesta, senza bisogno di sapere se ci sono cache, proxy , firewall , tunnel o qualsiasi altra cosa tra essa e il server che memorizza le informazioni. L'applicazione, tuttavia, deve comprendere il formato delle informazioni restituite (la rappresentazione ), che di solito è un documento HTML o XML, ma può anche essere un'immagine o altro contenuto.

REST vs. RPC

Un'applicazione Web RESTful richiede un approccio di progettazione diverso rispetto a un'applicazione basata su RPC (Remote Procedure Call). In RPC, l'enfasi è sulla diversità delle operazioni di protocollo, o verbi ; ad esempio un'applicazione RPC potrebbe definire operazioni come:

  • getUser()
  • Aggiungi utente()
  • rimuoviUtente()
  • updateUser()
  • getLocation()
  • Aggiungi luogo()
  • rimuoviPosizione()
  • aggiornamentoPosizione()
  • listUsers()
  • listLocations()
  • trovaPosizione()
  • trovautente()

In REST, al contrario, l'enfasi è sulle risorse, o nomi ; soprattutto nei nomi assegnati a ciascun tipo di risorsa. Ad esempio, un'applicazione REST potrebbe definire alcuni tipi di risorse assegnando loro questi nomi:

  • Utente {}
  • Posizione {}

Ogni risorsa dovrebbe avere il proprio identificatore, ad esempio http://www.example.org/locations/us/ny/new_york_city . I client lavoreranno con queste risorse tramite operazioni HTTP standard, come GET per scaricare una copia della risorsa. Nota come ogni oggetto ha il proprio URL e può essere facilmente memorizzato nella cache, copiato e aggiunto ai segnalibri. Il POST viene in genere utilizzato per azioni con effetti collaterali, come l'invio di un ordine di acquisto o l'aggiunta di determinati dati a una raccolta.

Ad esempio, il record per un utente potrebbe essere simile a questo: 

<utente>
 <name>Massimiliano Alessandro</name>
 <sesso>maschio</sesso>
 <location href="http://www.example.org/locations/us/ny/new_york_city">New York, NY, USA</location>
</utente>

Per aggiornare la posizione dell'utente, un client REST potrebbe prima scaricare il record XML precedente utilizzando GET. Il client modificherà quindi il file per cambiare la posizione e caricarlo sul server utilizzando HTTP PUT.

Si noti, tuttavia, che i verbi HTTP (POST, GET, PUT, DELETE) non forniscono alcun meccanismo standard per l'individuazione delle risorse: non esiste alcuna operazione LIST o FIND in HTTP, che corrisponderebbe alle operazioni list*() e trova . *() nell'esempio RPC. Invece, le applicazioni basate sui dati REST risolvono il problema trattando una raccolta di risultati di ricerca come un altro tipo di risorsa , richiedendo ai progettisti di applicazioni di conoscere URL aggiuntivi per visualizzare o cercare ogni tipo di risorsa.

Ad esempio, una richiesta GET HTTP sull'URL http://www.example.org/locations/us/ny/ potrebbe restituire un collegamento a un elenco di file XML con tutte le possibili posizioni a New York, mentre una richiesta GET al URL http://www.example.org/users?surname=Michaels potrebbe restituire un elenco di collegamenti a tutti gli utenti con il cognome "Michaels".

REST fornisce alcune indicazioni su come eseguire questa operazione come parte del suo vincolo "ipermedia come mezzo dello stato dell'applicazione", che suggerisce l'uso di un linguaggio dei moduli (come un modulo HTML) per specificare le query con parametri.

L' iniziativa OpenSearch di A9.com tenta di standardizzare le ricerche utilizzando REST stabilendo specifiche per la scoperta di risorse e un formato generico da utilizzare con i sistemi basati su REST, inclusi RDF , XTM , Atom , RSS (nelle sue varie forme) e XML con XLink per gestire i collegamenti.

Principi

Nella sua dissertazione originale del 2000 [ 1 ] , Roy T. Fielding definisce REST come uno "...stile architettonico per sistemi ipermediali distribuiti, descrivendo i principi di ingegneria del software che guidano REST e le costanti di interazione scelte per mantenere tali principi... Questi principi sono:

  1. Architettura client-server . Sottolinea la separazione delle responsabilità e la portabilità . Meno il server conosce il client, più la loro interazione è disaccoppiata e più facile è cambiare i componenti. Per definizione, REST è un'architettura progettata per funzionare con sistemi distribuiti centralizzati, al contrario di quelli che non utilizzano un server come nodo principale, ad esempio attraverso un'architettura peer-to-peer o P2P .
  2. Assenza di stato . Lo stato viene salvato e mantenuto sul client e non sul server. Cioè, le richieste devono fornire tutte le informazioni necessarie per essere eseguite su un server che non mantiene stati, quindi non salva il contesto tra le chiamate per lo stesso client. Ciò non significa che il server non possa cambiare contesto e facilitare la transizione al client. A tal fine vengono normalmente utilizzati reindirizzamenti delle richieste ; in modo che il client effettui solo una richiesta e il server la elabori su un endpoint o risorsa e la reindirizzi a un altro per continuare l'elaborazione lì. Ciò avviene in modo trasparente per il client ed è comune, ad esempio, nei casi d'uso relativi alla registrazione e al successivo login automatico: il server crea l'account, genera un token di sessione e invece di restituirlo al client chiama l' URI di login –che aumenterebbe i tempi, poiché ogni richiesta è costosa per i client–, la inoltra a detto endpoint di login stesso, restituendo al client la risposta finale dell'ultima richiesta effettuata.
  3. Abilitazione e utilizzo della cache . Tutte le richieste devono dichiarare se sono memorizzabili nella cache o meno, un modo standard per farlo è con le intestazioni di controllo della cache HTTP . In questo modo, le risposte memorizzate nella cache possono essere inviate da qualsiasi punto della rete senza che la richiesta raggiunga il server. Sebbene nel caso di un'API dinamica ciò possa sembrare inutile, può far risparmiare sui costi in caso di dati immutabili, come le definizioni.
  4. Sistema a strati. È correlato alla suddetta separazione delle responsabilità e afferma che un cliente dovrebbe conoscere solo il livello a cui sta parlando. In altre parole, non dovrebbe tener conto di aspetti specifici, come le particolarità della banca dati utilizzata; o astrazioni come cache , proxy o bilanciatori di carico coinvolti. Se è necessaria la sicurezza, è necessario aggiungerla ai servizi Web, consentendo a logica e sicurezza di rimanere separate.
  5. Interfaccia uniforme.
    1. Individuazione delle risorse nelle richieste. Come indicato nella descrizione in questa pagina, le richieste identificano le singole risorse. Tuttavia, REST sottolinea che le risorse sono concettualmente separate dalle rappresentazioni restituite dal server ( HTML , XML , JSON ...). Il tipo di formato può essere specificato nelle intestazioni HTTP e, attraverso la negoziazione del contenuto, il server e il client possono concordare la risposta che il primo invierà e che il secondo si aspetta.
    2. Manipolazione delle risorse attraverso le rappresentazioni. La specifica REST cerca di economizzare il più possibile le richieste. Pertanto, quando un client possiede la rappresentazione di una risorsa, inclusi eventuali metadati associati , dispone di informazioni sufficienti per modificare o rimuovere lo stato della risorsa. Cioè, attraverso gli strumenti che REST promuove (uso di API autodocumentanti , descrittivi, verbi HTTP...), il client può sapere come prevedere il risultato atteso di fare qualsiasi operazione su una risorsa prima ricevuta con un GET.
    3. Messaggi autodescrittivi. L'idea di un messaggio auto-descrittivo è quella di contenere tutte le informazioni di cui il cliente ha bisogno per capirlo. Pertanto, non dovrebbero esserci ulteriori informazioni in una documentazione separata o in un altro messaggio.
    4. Hypermedia come motore dello stato dell'applicazione ( HATEOAS ) Una volta effettuato l' accesso all'URI dell'applicazione iniziale , un client REST dovrebbe essere in grado di utilizzare i collegamenti forniti dinamicamente dal server per scoprire tutte le risorse disponibili di cui ha bisogno. Mentre il processo continua, il server risponde con un testo che include collegamenti ad altre risorse attualmente disponibili. Ciò elimina la necessità per il client di avere informazioni scritte nel codice ( hardcoded) riguardanti la struttura o riferimenti dinamici all'applicazione.

A causa dell'estensione di queste linee guida e delle particolarità di ogni progetto, dominio aziendale e API , può essere complesso combinare tutti i principi descritti da REST nella stessa specifica. Per questo motivo, il modello di maturità di Richardson descrive i livelli attraverso i quali passa una specifica API REST dal momento in cui viene creata fino al suo perfezionamento mediante l'acquisizione di controlli ipermediali. Questi livelli sono:

  1. Livello 0. I servizi hanno un unico URI che accetta l'intera gamma di operazioni supportate dal servizio, con risorse vagamente definite. Non è considerata un'API RESTful .
  2. Livello 1 . Introduce risorse e consente di effettuare richieste a singoli URI per azioni separate invece di esporre un punto di accesso universale. Le risorse sono ancora generalizzate ma è possibile identificare un'area un po' più specifica. Il primo livello non è ancora RESTful, ma è più orientato all'acquisizione della capacità di essere.
  3. Livello 2. Il sistema inizia a utilizzare i verbi HTTP. Ciò consente una maggiore specializzazione e generalmente comporta la divisione delle risorse in due: una per ottenere solo i dati (GET) e un'altra per modificarli (POST), sebbene sia possibile anche un grado di granularità maggiore. Uno degli svantaggi di fornire un sistema distribuito con più di una richiesta GET e POST per risorsa può essere la maggiore complessità del sistema, anche se il consumo di dati da parte dei client API è notevolmente semplificato.
  4. Livello 3. L'ultimo livello introduce la rappresentazione ipermediale, chiamata anche HATEOAS . Questa rappresentazione viene effettuata da elementi incorporati nei messaggi di risposta delle risorse, che consentono al cliente che invia la richiesta di stabilire una relazione tra le singole entità di dati. Ad esempio, una richiesta GET a un sistema di prenotazione di hotel potrebbe restituire il numero di camere disponibili insieme ai collegamenti per prenotare camere specifiche.

Differenze con SAPONE

Mentre un'architettura REST è fondamentalmente focalizzata sui dati (risorse), un'architettura che utilizza il protocollo SOAP è più orientata verso servizi che consentono di operare con tali dati. Spesso è possibile commettere l'errore di pensare che SOAP sia anche un altro tipo di architettura; tuttavia, come indica il nome, si tratta di un protocollo , quindi la sua eventuale implementazione è più ristretta e, in cambio, più standardizzata . Ciò ha una rilevanza speciale nel tipo di messaggi che i server inviano o ricevono: i client REST di solito inviano informazioni in HTML o XML , mentre un'implementazione SOAP normalmente opta per quest'ultimo; avendo una tipizzazione forte , con un linguaggio più dettagliato di JSON –molto diffuso nei servizi che implementano architetture REST– e richiedendo una maggiore larghezza di banda per trasmissione.

D'altra parte, i servizi REST devono essere testabili tramite browser per essere RESTful, quindi il servizio stesso deve controllare se restituisce contenuto compatibile con la macchina o una presentazione leggibile dall'uomo in base al contesto . Per testare un'implementazione SOAP è necessario utilizzare strumenti ad hoc come la nota SoapUI . Inoltre, l'uso delle librerie è più diffuso in quest'ultima opzione, lasciando REST riservato solo alle URI che rappresentano le risorse come sopra descritto.

REST si basa sul principio della lettura come operazione più frequente, quindi la maggior parte delle richieste sarà di tipo GET; mentre SOAP è più costruito con le richieste POST. A causa di queste ultime e di risorse non specifiche, SOAP può portare allo sviluppo di client più complessi di quelli che potrebbero essere costruiti con i servizi REST.

Vantaggi e svantaggi

Come ogni proposta architettonica, la sua adozione deve essere valutata olisticamente rispetto al rapporto benefici-costi la cui realizzazione può comportare. Anche se è vero che oggi gran parte delle API –soprattutto quelle pubbliche o aperte al consumo da parte di terzi– sono progettate per essere REST o RESTful e, quindi, c'è un certo consenso tra i programmatori su cosa aspettarsi, la standardizzazione del protocollo SOAP a livello di implementazione rende facile ignorare molte decisioni lasciate aperte in REST. D'altra parte, la visibilità a cui sono esposti gli URI pubblici può rappresentare un problema di sicurezza , oltre alle limitazioni tecniche dovute alla lunghezza massima dei parametri. Quest'ultimo può essere risolto con richieste POST, che solitamente SOAP consiglia, ed è particolarmente utile nel caso di invio di una grande quantità di informazioni o dati binari. In generale, REST può essere una soluzione in qualche modo più semplice da implementare sul client e sul server, con molti framework che lo offrono per impostazione predefinita , come nel caso di Django . Tuttavia, SOAP può salvare le decisioni sui dettagli di implementazione e offrire operazioni in modo più trasparente al cliente, pubblicando i servizi specifici disponibili su un determinato endpoint, piuttosto che astrazioni di dati.

Implementazioni pubbliche

Poiché la definizione di REST è molto ampia, è possibile affermare che esiste un numero enorme di applicazioni REST sul Web (praticamente qualsiasi cosa accessibile tramite una richiesta HTTP GET). In modo più restrittivo, a differenza dei servizi Web e RPC, REST può essere trovato in diverse aree del Web:

Probabilmente ci sono molte altre implementazioni simili.

In ogni caso va tenuto conto che molte delle implementazioni sopra descritte non sono completamente RESTful, ovvero non rispettano tutte le restrizioni imposte dall'architettura REST. Tuttavia, sono tutti ispirati a REST e rispettano gli aspetti più significativi e restrittivi della sua architettura, in particolare la restrizione "interfaccia uniforme". Questi servizi sono stati chiamati "Accidentally RESTful" .

Riferimenti

  1. ^ a b Fielding, Roy Thomas (2000). Stili architettonici e progettazione di architetture software basate su rete . Università della California, Irvine. doi : 10.5555/932295 . Estratto il 16 aprile 2021 . 
  2. ↑ Specifiche OneFlow, versione 5.12

Vedi anche

Estratto da « https://es.wikipedia.org/w/index.php?title=Transferencia_de_Estado_Representacional&oldid=140748018 »