Servizi REST. Fielding, R.T. Architectural Styles and the Design of Network-based Software Architectures. PhD Thesis, 2000.

Transcript

1 Luca Cabibbo Architettura dei Sistemi Software dispensa asw530 marzo 2019 The World Wide Web is arguably the world's largest distributed application. Understanding the key architectural principles underlying the Web can help explain its technical success and may lead to improvements in other distributed applications. 1 Roy Thomas Fielding - Fonti Fielding, R.T. Architectural Styles and the Design of Network-based Software Architectures. PhD Thesis, Newman, S. Building Microservices: Designing Fine-grained Systems. O Reilly, Chapter 4, Integration Webber, J., Parastatidis, S., and Robinson, I. REST in Pratice: Hypermedia and Systems Architecture. O Reilly, Richardson, L. and Amundsen, M. RESTful Web APIs. O Reilly,

2 - Obiettivi e argomenti Obiettivi presentare i servizi REST confrontare i servizi SOAP con i servizi REST Argomenti introduzione ai servizi REST lo stile REST servizi REST discussione 3 * Introduzione ai servizi REST Un servizio web (web service) è un componente software, che ha lo scopo di implementare una funzionalità o un servizio di business di un organizzazione, che può essere scoperto e invocato dai suoi consumatori mediante un interfaccia aperta e tramite tecnologie standard del web oltre ai servizi web SOAP (discussi in una precedente dispensa), criticati per la loro pesantezza esistono anche altre tecnologie a servizi, più leggere che sostengono ancora l interoperabilità, ma che offrono migliori garanzie su prestazioni e scalabilità, e che in genere sono anche più semplici da programmare tra queste tecnologie, la più diffusa è quella dei servizi REST RESTful web service(s), chiamati anche RESTful web API(s) i servizi REST sono basati sullo stile architetturale REST per questo è utile, come premessa, introdurre lo stile REST (anche se non entreremo troppo nei dettagli di questo stile) 4

3 * Lo stile REST REST (Representational State Transfer) è uno stile architetturale che è stato proposto da Fielding (uno dei creatori di HTTP) per descrivere l architettura del world-wide web moderno, e per guidare la progettazione e l implementazione di applicazioni web Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use. si noti che lo stile REST è stato definito prima di quelli che oggi sono chiamati servizi REST (e indipendentemente da essi) 5 Risorse Uno dei concetti centrali dello stile REST è quello di risorsa una risorsa (resource) è ogni elemento informativo di interesse a cui può essere attribuito un nome un documento, un immagine, un concetto o una persona, ma anche un operazione o un servizio ad es., il corso di Architettura dei Sistemi Software a Roma Tre oppure il tempo a Roma oggi un identificatore di risorsa (resource identifier) è un nome univoco usato dai componenti (ad es., un servizio o un suo client) per identificare una specifica risorsa ad es., un URI (Uniform Resource Identifier) ad es., l URI per la risorsa corso di Architettura dei Sistemi Software a Roma Tre 6

4 Rappresentazioni I componenti (servizi e client) possono specificare e eseguire azioni su una risorsa usando una rappresentazione per descrivere lo stato corrente oppure lo stato desiderato della risorsa, e per trasferire la rappresentazione della risorsa tra componenti una rappresentazione è un gruppo di dati (e metadati) per una risorsa (di solito auto-descrittivo) ad es., un documento XML oppure JSON quando un client accede a una risorsa, non gli viene restituita la risorsa, ma piuttosto una rappresentazione della risorsa inoltre, per aggiornare una risorsa, un componente può comunicare la rappresentazione desiderata della risorsa 7 Rappresentazioni 8 Ci possono essere rappresentazioni differenti per le risorse ad es., un documento XML, JSON, HTML o PDF, un immagine JPEG, oppure una rappresentazione binaria basata, ad es., su Protocol Buffer o Thrift il protocollo HTTP supporta la negoziazione del contenuto tramite l Accept Header dunque, un client può specificare la rappresentazione desiderata per una risorsa, ad es., HTML oppure JSON in questo modo un servizio può restituire, a partire da un certo URI, sia una rappresentazione della risorsa che è una pagina web visualizzabile ad un utente umano, che una rappresentazione comprensibile da un client software l uso delle rappresentazioni consente di disaccoppiare completamente il modo in cui i componenti memorizzano internamente le risorse dal modo in cui le condividono esternamente

5 Caratteristiche dello stile REST Caratteristiche generali dello stile architetturale REST è uno stile architetturale di tipo client-server i servizi sono di tipo stateless sostiene scalabilità e disponibilità è possibile fare caching delle risposte dei servizi sostiene scalabilità e prestazioni è un architettura a strati un client in genere non sa se sta comunicando con un server che eroga effettivamente il servizio oppure con un intermediario uso di un interfaccia uniforme tra componenti l accesso uniforme alle risorse sostiene flessibilità code on demand (opzionale) 9 * Lo stile architetturale REST è stato proposto per descrivere l architettura generale del web ma può anche essere usato come guida per la definizione di servizi REST in effetti, esistono diverse varianti dei servizi REST ad es., i servizi REST sono comunemente basati sull uso di HTTP ma questo non è obbligatorio nel seguito di questa dispensa viene descritta un interpretazione comune dei servizi nello stile REST, basata su HTTP per un esempio concreto, si veda 10

6 Principi per servizi nello stile REST Principi che guidano la definizione di un servizio REST identificazione delle risorse tramite URI un servizio REST espone un insieme di risorse che sono l obiettivo delle interazioni con i client identificate da URI interfaccia uniforme le risorse vengono manipolate in modo uniforme, tramite le operazioni di HTTP (come PUT, GET, POST e DELETE) il significato attribuito a queste operazioni è discusso più avanti 11 Principi per servizi nello stile REST Principi che guidano la definizione di un servizio REST messaggi auto-descrittivi le risorse sono disaccoppiate dalle loro rappresentazioni e il loro contenuto può essere acceduto sulla base di più formati ad es., testo, XML, JSON, PDF, JPEG ogni richiesta di un client contiene informazioni sufficienti a descrivere come il servizio possa elaborare la richiesta ogni risposta da un servizio contiene informazioni sufficienti a descrivere come il client possa elaborare la risposta 12

7 Principi per servizi nello stile REST Principi che guidano la definizione di un servizio REST rappresentazione ipermediale se un client deve poter accedere ad altre risorse correlate a una sua richiesta, gli identificatori di queste risorse sono comunemente incluse nella rappresentazione restituita (HATEOAS, Hypermedia As The Engine Of Application State) interazioni stateful basate su collegamenti ipertestuali le interazioni con le risorse sono di per sé stateless tuttavia, sono possibili interazioni stateful, sulla base di un trasferimento esplicito dello stato delle conversazioni ad es., riscrittura di URI, cookie, campi nascosti 13 Esempio di servizio nello stile REST Un esempio di servizio REST è un servizio che gestisce una o più collezioni omogenee di risorse ad esempio, un insieme di corsi e un insieme di docenti il servizio definisce, per ciascuna collezione, un URI di base chiamato collection URI ad es., e ciascuna istanza di risorsa ha un proprio URI element URI ad es., e le operazioni offerte dal servizio sono messe in corrispondenza con le operazioni HTTP, come GET, PUT, POST e DELETE sulla base di un interfaccia uniforme le rappresentazioni potrebbero essere scambiate, ad es., in formato XML oppure JSON 14

8 Esempio di servizio nello stile REST Interfaccia uniforme di un servizio nello stile REST operazioni riferite ad un collection URI GET restituisce tutti gli elementi della collezione PUT sostituisce la collezione con un altra collezione POST crea un nuovo elemento della collezione e gli assegna un nuovo URI (e lo restituisce) DELETE cancella l intera collezione 15 Esempio di servizio nello stile REST Interfaccia uniforme di un servizio nello stile REST operazioni riferite ad un element URI GET restituisce una rappresentazione di uno specifico elemento della collezione PUT crea un nuovo elemento della collezione, oppure lo aggiorna POST considera l elemento della collezione come un altra collezione, e ne aggiunge un elemento (in modo analogo a quanto fa POST con riferimento ad un collection URI) DELETE cancella l elemento della collezione 16

9 HATEOAS Secondo il principio HATEOAS, le relazioni tra risorse vanno modellate in modo ipermediale, tramite collegamenti (link) tra risorse, da includere nelle loro rappresentazioni dunque, quando un servizio restituisce una risorsa, la sua rappresentazione può includere i collegamenti ad altre risorse (che possono essere sia risorse informative che operazioni) ad es., insieme a un corso, vengono restituiti i collegamenti ai suoi appelli d esame e insieme a un appello d esame, un collegamento per prenotarsi all appello d esame ad es., in XML, l elemento link prevede gli attributi href (l URI della risorsa) e rel (che indica il tipo di relazione) 17 in questo modo, un client ha bisogno di conoscere solo un punto di ingresso ad un servizio dopo di che, la sua navigazione può proseguire seguendo solo dei collegamenti l accoppiamento verso un servizio dai suoi client è ridotto dunque il servizio può evolvere in modo più flessibile Sviluppo di servizi REST L adozione dei servizi REST è favorita dall ampia diffusione di infrastrutture per HTTP e per applicazioni web nonché dall impiego di standard semplici e spesso già noti agli sviluppatori lo sviluppo di servizi REST è inoltre semplificato dalla disponibilità di opportune librerie, API e framework si pensi, ad es., al supporto a REST fornito dal framework Spring oppure a librerie per Java come JAX-RS l uso di queste librerie può semplificare, in particolare, la gestione di HTTP (sia lato server che lato client) che le trasformazioni tra risorse e rappresentazioni (che può avvenire in modo trasparente sia per il servizio che per i suoi client) 18

10 e interoperabilità I servizi REST sono interoperabili e dunque possono essere considerati servizi web infatti sono basati su protocolli standard del web, come HTTP e XML l interoperabilità è inoltre sostenuta dalla possibilità di usare diversi formati per l interscambio dei dati che sono indipendenti dai linguaggi di programmazione e dalle piattaforme come XML e JSON l interfaccia di un servizio REST è costituita da un insieme di URI e di operazioni HTTP su questi URI e può essere scoperta dai client del servizio in modo progressivo, sulla base di HATEOAS e dei collegamenti tra risorse c è una proposta di standard per la descrizione di servizi REST (WADL, con obiettivi simili a quelli di WSDL) ma questo standard è controverso e poco diffuso, poiché è in contraddizione con il principio HATEOAS 19 * Discussione I servizi REST sono un altra soluzione tecnologica per l interoperabilità tra componenti/servizi software distribuiti ed eterogenei sulla base di alcuni standard fondamentali del web e di altri standard di uso comune l adozione dei servizi REST è di solito semplice poiché le infrastrutture necessarie sono spesso già disponibili è possibile scrivere client di servizi REST in un ampia varietà di linguaggi di programmazione grazie all uso di URI e collegamenti ipertestuali, è possibile scoprire risorse web senza l uso di un registry centralizzato è possibile adottare le soluzioni per la scalabilità e per la sicurezza già sviluppate per il web ad es., basate su caching, clustering, load balancing e standard per la sicurezza compatibili con HTTP 20

11 Discussione I servizi REST presentano però anche alcuni inconvenienti i servizi REST sono adatti soprattutto a scenari con una bassa complessità, per la gestione di risorse informative semplici le infrastrutture per i servizi REST non supportano un ampio insieme di attributi di qualità che, se richiesti, devono spesso essere gestiti direttamente dagli sviluppatori dei servizi i servizi REST vengono acceduti tramite HTTP, in modo sincrono per questo, l integrazione di applicazioni può essere problematica usando le sole operazioni HTTP, può essere difficile stabilire una buona definizione dell interfaccia di un servizio REST HTTP ha un vocabolario molto limitato, all opposto di quanto avviene con i linguaggi a oggetti i servizi REST non hanno un interfaccia descritta esplicitamente questo può rendere più difficile la loro fruizione 21 e SOAP a confronto Vantaggi dei servizi REST l adozione è più semplice poiché fa riferimento a standard e tecnologie più semplici più semplice realizzare client di servizi tecnologia più leggera e migliori soluzioni per la scalabilità il vantaggio principale di REST vs. SOAP è la semplicità Vantaggi dei servizi SOAP applicabile anche in contesti applicativi complessi supporto standardizzato per la descrizione delle interfacce dei servizi e per la scoperta dei servizi supporto standardizzato per la composizione di servizi miglior supporto per diversi attributi di qualità il vantaggio principale di SOAP vs. REST è la completezza 22