REST REpresentational State Transfer

Transcript

1 LEZIONE 21 REST REpresentational State Transfer Anno Accademico Il contesto L'evoluzione di internet impone la realizzazione di sistemi distribuiti scalabili, in grado di Garantire l'interoperabilità tra piattaforme differenti Consumare e/o produrre contenuti indicizzabili, collegabili, dotati di molteplici rappresentazioni alternative Essere semplici da sviluppare e manutenere Supportare il comportamento elastico offerto dai modelli "cloud" (pay per use) 1 Il fatto che HTTP sia stateless è stato vissuto come un grosso impiccio. Quando avevo a che fare con client "stupidi", gestire client complessi era un lavoro demandato al server (per questo motivo sono stati implementati i cookie e le sessioni). L'uso delle sessioni è però anch'esso un grosso impiccio: quando mi ritrovo in una realtà di comunicazione machine-to-machine (es.: GTT va dal signor Google Map e gli chiede qual è il percorso. GTT fa dunque da client verso Google Map) la cosa vive male con i concetti di cookie e sessione. Questo perchè noi non vogliamo basarci su meccanismi di autenticazione. Inoltre non vogliamo avere dipendenze dal tipo di piattaforma: quando a Google chiedo le indicazioni per andare da un posto all'altro, posso ricevere diversi formati di risposta (XML, JSON, rappresentazione testuale...) Dev'essere poi semplice sia lo sviluppo iniziale che la manutenzione: se a un certo punto Google Map aggiunge la bicicletta, l'impatto sulle modifiche che devo fare dev'essere il più basso possibile. 2 Le proprietà fondamentali (1) Eterogeneità Capacità di fare interoperare dispositivi diversi in termini di risorse hardware, sistemi operativi, linguaggi di programmazione, vincoli di gestione,... Scalabilità Capacità di garantire il mantenimento di livelli di servizio al crescere del numero di utenti/transazioni Possibilità di evolvere Proprietà di un'architettura di non introdurre vincoli strutturali che impediscano la manutenzione evolutiva di un servizio Ci sono due soluzioni alternative: - servizi web, protocollo SOAP. SOAP sembrava ragionevole perchè supportava bene l'eterogeneità - scalabilità: SOAP qui casca perchè quando io voglio chiedere un qualcosa a un servizio remoto devo scrivere un XML, imbustarlo e quant'altro. C'è firma elettronica, facilità nel gestire le transazioni, bello. Però per mandare una richiesta mandiamo in giro 5K-10K per ricevere 5K-10K che magari contengono un solo FALSE. - l'interoperabilità si ottiene compilando del codice (wrappandolo). Otteniamo quello che vogliamo ma ho un sacco di roba da fare. Tutte le richieste SOAP vengono passate in POST: questo perchè siccome non si sa a priori se il metodo accede in sola lettura o in lettura/scrittura (= non so se il dato è cacheabile) mando via POST così il dato non è cacheabile. Tutto bello, ma perdo le peculiarità di HTTP. 3 Le proprietà fondamentali (2) Affidabilità/resilienza Capacità di un sistema di mantenere i propri livelli di servizio anche a fronte di malfunzionamenti locali delle sue parti Efficienza Misura del rapporto tra le risorse impegnate per offrire un servizio e il valore del risultato prodotto Prestazioni Valutazione assoluta del tempo/risorse necessarie per erogare un dato servizio 4

2 Il modello REST REST è uno stile con il quale realizzare architetture distribuite in grado di non ostacolare il raggiungimento delle proprietà enunciate Particolarmente adatto per applicazioni distribute che durano a lungo nel tempo Acronimo di Representational State Transfer Concetto introdotto da Roy Fielding nella sua tesi di dottorato (2000) Un tizio allora ha cominciato a dire che non scala e non fa leva su HTTP. Per questo ha creato REST, uno "stile" di fare le cose. L'idea è che esiste già un'infrastruttura di trasporto sottostante: si sfrutta dove possibile, cercando di non violare i suoi principi base (= stateless). Con le sessioni è però facile gestire un lavoro di un singolo utente. L'idea di REST è quella di trasferire una rappresentazione dello stato all'utente, in modo che l'utente possa riprenderla in qualunque momento. Va dunque molto bene per realizzare applicazioni distribuite in cui le sessioni di lavoro tendenzialmente sono d'impiccio (perchè vanno a scadere). 5 I principi fondamentali (1) Architettura client-server priva di stati Per garantire implementazioni semplici e scalabili Un server ospita uno o più servizi Ogni servizio gestisce un insieme di "informazioni", ciascuna delle quali Ha un nome univoco su scala globale (URI) Può avere molteplici rappresentazioni tra loro semanticamente equivalenti (testo semplice, XML, JSON,...) Supporta operazioni elementari di tipo CRUD 6 Il principio di base è essere stateless: se avessi un'architettura con stati espliciti avrei testing e sviluppo più complessi. Una macchina può ospitare uno o più servizi: ogni servizio gestisce un insieme di informazioni (= entità rappresentabile in modo digitale e con un ID univoco, del tipo L'HTTP, che permette di trasferire e interagire con delle URL, ammette già al suo interno una forma di negoziazione dei formati: quando io chiedo una URL posso dire Accept-Encoding (= questa cosa mi va bene se me la dai nei seguenti formati). Il tizio di REST ha usato questa caratteristica in un modo intelligente. HTTP ha un sacco di verbi: se io li guardo bene, posso fare un parallelismo con le opzioni CRUD di una base dati. Se io devo fare un Retrieve faccio GET (= dammene una copia, lecito cachearla). Se la voglio modificare con Update la mando con POST (= non idempotenti e non cacheabili). Se devo fare una Create uso il verbo PUT (= idempotenti ma non cacheabili). I principi fondamentali (2) Una data URL può riferirsi a tutta una serie di cose. E' buon senso usare URL che facciano capire cosa si sta chiedendo. Le informazioni associate ad una URL possono essere relative a Singole voci (persone, oggetti, eventi,...) Collezioni di voci (liste, insiemi) Risultati di computazioni funzionali Esempi di URL Elenca tutti gli utenti Descrive l'utente il cui ID è u23 Elenca tutte le fatture dell'utente con ID u23 Descrive la fattura i32 dell'utente u23 7 Collegamenti Poiché ogni entità ha un nome univoco, è possibile legare entità differenti specificandone il nome Richiedendo la URL corrispondente ad un identificativo, un sistema può acquisire ulteriori informazioni sull'entità <order self=' > <amount>23</amount> <product ref=' /> <customer ref=' /> </order> Ho dunque la possibilità di descrivere un oggetto elencando gli attributi o identificando la URL a cui devo accedere per avere ulteriori informazioni. 8

3 Uso di metodi standard Siccome HTTP ha supporto nativo per le operazioni CRUD posso fare queste operazioni. Il protocollo HTTP costituisce un ambiente naturale nel quale le richieste di tipo CRUD possono essere mappate sulle caratteristiche del trasporto Ogni richiesta consiste di un'azione (verbo) e di una URL (nome) Operazione Metodo Oggetto Crea (voce singola) POST URL della collezione Leggi (elenco di voci) GET URL della collezione Leggi (voce singola) GET URL dell'elemento Aggiorna (voce singola) PUT URL dell'elemento Cancella (voce singola) DELETE URL dell'elemento 9 Negoziare il formato (1) Ogni elemento può essere rappresentato in formati alternativi JSON, XML, CSV,... HTTP dispone di un meccanismo nativo per negoziare il formato di dati scambiati Basato sull'uso di intestazioni di tipo "Accept: ", "Content-type:" o sulle convenzioni delle URL Il server può offrire molte rappresentazioni alternative, il client ne può chiedere una specifica Siccome i client possono essere molto diversi posso usare la header di negoziazione del contenuto per far sapere in che formato si desidera una data informazione. Un servlet fatto bene rappresenta tante rappresentazioni alternative. 10 Negoziare il formato (2) GET /foo HTTP/1.0 Accept: application/json GET /foo.json HTTP/1.0 GET /foo HTTP/1.0 Accept: application/json,application/xml HTTP/ Ok Content-type: application/json Content-length:16 {"a"=123,"b"="" 11 Implementare servizi REST Oracle fornisce due specifiche alternative per la realizzazione di servizi REST in JavaEE Java API for XML Web Services (JAX-WS, JSR-224) html Java API for RESTful Web Services (JAX-RS, JSR-311) Parte della specifica JavaEE 6 Supporta appieno il modello architetturale REST Utilizza le annotazioni come strumento per configurare il comportamento di un servizio web Di base, quello che c'era da dire su REST è finito. Se voglio implementare un server REST banalmente scrivo un Servlet: sulla base della URL che ho ricevuto genero il contenuto. Ovviamente fare questa cosa tutta a mano è faticosa: vengono date due alternative - JAX-WS: abbandonata - JAX-RS: supporta completamente l'architettura REST e dice "tu vuoi fare un servizio REST in Java? Facile, mi metti alcune annotazioni e includi Jersey" 12

4 Il framework Jersey Implementazione di riferimento della specifica JAX-RS Disponibile con licenza open source, può essere integrato in prodotti commerciali o essere esteso con comportamenti specializzati Mette a disposizione un servlet specializzato per servire le richieste rivolte a POJO opportunamente annotati com.sun.jersey.spi.container.servlet.servletcontainer Può essere mappato su tutte le URL (/*) Jersey di base è un JAR che noi includiamo nel nostro progetto (tipicamente con Maven) e ci dice: "nel tuo Container metti questo Servlet qui". Il servlet va a vedere, nelle classi che noi diciamo, chi ha l'annotazione opportuna e usa l'annotazione per creare direttamente il servizio web che risponde nel modo in cui noi vogliamo. 13 Configurazione Maven Questo è quello di cui abbiamo bisogno in Maven. <dependency> <groupid>com.sun.jersey</groupid> <artifactid>jersey-servlet</artifactid> <version>1.18.1</version> </dependency> <dependency> <groupid>javax.ws.rs</groupid> <artifactid>jsr311-api</artifactid> <version>1.1.1</version> </dependency> <dependency> <groupid>com.sun.jersey</groupid> <artifactid>jersey-json</artifactid> <version>1.18.1</version> </dependency> 14 Esporre una risorsa (1) Ciascuna risorsa esposta da un server è rappresentata da una classe Java Annotata Il parametro dell'annotazione indica il frammento relativo di URL che deve essere giustapposto al nome della URL su cui è mappato il servlet globale import public class StockResource {... public String getstockinfo() { return "This is Stock Information"; Avendo creato un progetto Maven di tipo web e incluse queste dipendenze e averlo mappato in web.xml sulle URL che ritengo opportune, creiamo classi POJO e di fronte a queste classi mettiamo (= questa classe è delegata a rispondere a questo tipo di URL). 15 Esporre una risorsa (2) I metodi pubblici della classe possono essere mappati su una specifica azione HTTP tramite può essere ripetuta, per indicare un vincolo specifico sul metodo Il valore di ritorno può essere void, un tipo elementare (compresa una stringa) o un oggetto di tipo javax.ws.rs.core.response Di solito ha senso creare metodi diversi per azioni diverse, e anche qui usiamo annotazioni per distinguere. Volendo il singolo metodo potrebe essere ristretto (la classe serve tutte le richieste per /fatture, un certo metodo risponde solo a /fatture/dettaglio). Il metodo pubblico può ritornare void (va bene per operazioni come DELETE che non generano dati), un dato elementare (da boolean a String) oppure addirittura un oggetto annotato 16

5 Esempio {id = si risponde a users/21, users/46, users/ // Se il contesto applicativo è // allora // // GET // - gestito dal metodo getlist() // GET // - gestito dal metodo public class UsersResource String String getuser(@pathparam("id") String id) { Indicare i parametri Se contiente un valore racchiuso tra parentesi graffe, esso indica una componente variabile della URL E' possibile mappare automaticamente tale componente su un parametro di uno dei metodi pubblici, facendo precedere la definizione del parametro dalla Altre annotazioni possibili per l'estrazione di contenuti specifici presenti @FormParam I parametri volendo possono essere passati in forme alternative: se ad esempio è presente un cookie con un determinato nome, lo uso. E così via. 18 Sotto-risorse ) può anche essere usata, di fronte ad un metodo, per indicare che questo ritornerà una sotto-risorsa della risorsa public class SayHello { public /* risponde a GET/sayHello/lastName */ public String hello() { Negoziare il contenuto Ciascun metodo può definire quali tipi di contenuti consuma e/o produce Attraverso opportune indica quale tipo di rappresentazione viene generata nella risposta Se applicato a livello di classe, indica il tipo restituito da tutte le risposte (se non specificamente indica il tipo di dato atteso nella richiesta Questo verrà reso disponibile sotto forma di parametro in ingresso al metodo stesso Oltre ai metodi che mi servono per identificare una risorsa e alle annotazioni per i verbi, posso aggiungere di fronte ai singoli metodi annotazioni ulteriori per negoziare il contenuto. Produces: come devi interpretare il valore di ritorno? Consumes (va bene per chi ha delle entity in ingresso): posso usare il content-type per matchare il verbo. 20

6 Esempio public class SayHelloResource public String public String public void putxml(string content) { Descrivere il servizio web Il comportamento di un servizio web JSR-311 può essere descritto formalmente attraverso un documento in formato WADL Web Application Description Language Dialetto XML che fornisce funzionalità analoghe a quelle offerte da WSDL per servizi web di tipo SOAP Jersey può produrre automaticamente tale rappresentazione all'indirizzo Così come nel mondo SOAP si può preparare una classe e dire che la classe espone alcune cose, Jersey può esporre un WADL che ci restituisce un XML con i metodi esposti. Tale descrizione è consumabile da un programmatore o dal programma stesso. 22 Configurare il file web.xml E qui c'è la configurazione in web.xml. <?xml version="1.0" encoding="utf-8"?> <web-app...> <servlet> <servlet-name>jersey</servlet-name> <servlet-class> com.sun.jersey.spi.container.servlet.servletcontainer </servlet-class> <init-param> <param-name> com.sun.jersey.config.property.packages </param-name> <param-value> com.acme.helloworld.resources </param-value></init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>jersey</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> </web-app> Applicazioni ioni Internet 23 Interagire con un server REST Che è quello che avevamo fatto ai tempi del Raspberry. In fase di debug, risulta comodo utilizzare un plugin per il browser Che permetta di creare richieste personalizzate Indicando il metodo, il tipo di dato accettato, il corpo della richiesta Per firefox si può utilizzare Poster Oppure RESTClient 24

7 Interagire programmaticamente Jersey mette anche a disposizione un client HTTP per l'accesso a servizi REST Può essere utilizzato sia in applicazioni stand-alone che all'interno di server per accedere a servizi di terze parti Basato su un'architettura modulare che permette di cambiare il gestore della comunicazione HTTP Per default, viene utilizzato URLConnection, ma è possibile basare le richieste su Apache HTTPClient, Jetty HTTPClient e i client asincroni offerti dal middleware Grizzly <dependency> <groupid>com.sun.jersey</groupid> <artifactid>jersey-client</artifactid> <version>1.18.1</version> </dependency> 25 Oltre a esporre servizi verso il resto del mondo, possiamo anche consumarne. Questo è interessante perchè un sacco di roba (tipo Twitter, Google Maps,...) viaggia su REST. Ci sono situazioni in cui un server consuma dati forniti da molti altri servizi: Jersey, oltre a fornire il servlet e il core, ha nel proprio package un client HTTP REST pensato per queste situazioni. Si include utilizzando la dipendenza qui riportata. Il client è molto configurabile e quindi può basarsi su tante implementazioni alternative (usa Apache, usa le versioni asincrone,...). La libreria client Per creare un client per Jersey, dobbiamo partire creando un'istanza della classe Client, così come riportato. La classe javax.ws.rs.client.client costituisce il punto di partenza per la creazione di tutte le richieste Si istanzia dinamicamente tramite il metodo statico newclient() della classe ClientBuilder Tale metodo può ricevere un parametro di tipo ClientConfig che permette di configurare il comportamento del client (in termini di filtri, intercettori, connettori, proprietà,...) ClientConfig config = new ClientConfig(); config.connectorprovider(new GrizzlyConnectorProvider()); Client c = ClientBuilder.newClient( config ); 26 Identificare una risorsa Una volta costruito il client, diciamo che URL vogliamo interrogare. La URL è modellata con un oggetto WebTarget. Alla URL posso aggiungere "/..." oppure alcuni parametri. La classe WebTarget modella un risorsa rappresentata da una URL Viene costruita a partire dal metodo target(...) di Client Da oggetti di questo tipo, è possibile derivarne altri che indicano, in modo più specifico una risorsa all'interno dello spazio definito dalla URL WebTarget mainservice = client.target(" WebTarget contacts = mainservice.path("contacts"); WebTarget contactswithparams = contacts.queryparam("name","joe"); 27 Costruire la richiesta Il metodo request(...) di WebTarget permette di creare la descrizione di una richiesta Che viene rappresentata da oggetti di tipo Invocation.Builder Tale descrizione può essere decorata con intestazioni, cookies, richieste sul formato atteso, sulla codifica, sul linguaggio,... Si otterrà la risposta corrispondente tramite i metodi get(), post(...), put(...), delete(),... Invocation.Builder builder = contactswithparams.request(); builder.acceptencoding(media_type.text_plain_type); Response r = builder.get(); 28 Una volta arrivato al WebTarget definitivo devo costruire la richiesta. Quale dei quattro metodi voglio passare e quale tipo di risposta voglio ottenere?

8 Elaborare la risposta Gli oggetti di classe Response offrono diversi meccanismi per accedere alle informazioni restituite Il metodo getstatus() restituisce il codice di stato della richiesta Il metodo readentity(class c) cerca di trasformare il corpo della risposta ricevuta in un oggetto di classe c, che viene restituito I metodi getheaders(), getcookies(),... permettono di accedere alle rispettive informazioni int statuscode = r.getstatus(); String s= r.readentity(string.class); 29 La Response mi espone tutto quello che il server mi ha mandato indietro: posso vedere lo stato e accedere al dettaglio tramite read- Entity (che prende come parametro una classe e restituisce un oggetto istanza della classe se possibile, altrimenti lancia un'eccezione). Altre implementazioni Jersey non è l'unica via possibile. Il framework Restlet è un'implementazione completa, leggera, open-source dell'architettura REST Permette di realizzre sia applicazioni lato client che lato server Costituisce un tentativo di aderire pienamente allo spirito della filosofia REST 30 Chi usa REST SOAP è via via abbandonato. Google Maps e Google Search Yahoo Maps e Yahoo Search ebay API Amazon API Paypal API Skype API Twitter REST API molti altri 31 Riferimenti Web Services Programming (with Passion!) corso online A Brief Introduction to REST JAX-RS: Developing RESTful Web Services in Java Specifica JAX-RS Errori comuni nei sistemi REST <<< 32