Il Paradigma REST per lo sviluppo di applicazioni Web 2.0

Transcript

1 tesi di laurea Anno Accademico 2006/2007 Il Paradigma REST per lo sviluppo di applicazioni Web 2.0 relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Marcello Cinque candidato Antonio Alonzi Matr. 831/000205

2 Contributi Studio di: tecnologie tradizionali per lo sviluppo di applicazioni Web; tecnologie per il Web 2.0 (Ajax) e Web Services (WS); paradigma REST e Resource Oriented Architecture (ROA); Progetto e sviluppo di applicazioni di esempio per evidenziare le differenze tra i WS e REST.

3 Il Web 2.0 Applicazione Web come piattaforma (ad es. Google); Ogni client può diventare server: il web coinvolge tutta la rete (ad es. BitTorrent); Utente non solo utilizzatore ma creatore dell'applicazione (ad es. wiki, blog, flikr,...); Client intelligenti, non sempre all'interno di browser, capaci di gestire risorse rappresentate in linguaggi standard (XML, JSON,...); Feed RSS che permettono di abbonarsi all'applicazione e di essere computer-readeble;...

4 Ajax Capacità di distribuire l'intelligenza tra client e server; Richieste asincrone per: recuperare informazioni aggiuntive evitando il reload; invocare servizi; diminuire il traffico in rete richiedendo solo i dati necessari; Rich Client: funzionalità avanzate (ricerca, scorrimento elenco,...) possono essere implementate direttamente nel client. Pagina XMLHTTPRequest Server << crea >> registra onreadystatechange invio richiesta (Method, URI) ricezione risposta ascncrona modifica stato pagina

5 Web Services (SOA) Possibilità di creare dei servizi di supporto al normale web; Veloce progettazione e implementazione; Possibilità di fornire solo server: client di terze parti; Buon supporto Ajax tramite apposite librerie JavaScript; Ideale per una progettazione Model-View-Controller.

6 Svantaggi dei WS Request che utilizzano il protocollo HTTP per trasportare altri protocolli più complessi: SOAP e WSDL; Payload più lunghi: banda di trasmissione sprecata; Parsing di payload HTTP più complessi: CPU sprecata; Compatibilità non sempre garantita da tutti i framework di sviluppo.

7 REST e ROA REST (REpresentional State Transfer): paradigma per lo sviluppo di applicazioni distribuite sul web; Si sfruttano le capacità tipiche di HTTP, anziché usare HTTP come protocollo di trasporto; Si basa su ROA: l'applicazione è modellata come un'insieme di risorse, non di servizi; Ottima scalabilità grazie alla semplicità delle tecnologie Web; Veloce progettazione e programmazione; Miglior supporto per il mobile: semplicità e ampia compatibilità; Supporto Ajax trasparente.

8 ROA Risorsa come elemento chiave per l'applicazione; Uniform Interface: data dal protocollo HTTP; Stateless: grazie ad HTTP che porta ad una semplice progettazione; Addressability: riferirsi a risorse mediante un URI; Conenctedness: risorse sono legate tra loro. GET POST GET POST Utente Messaggio PUT DELETE PUT DELETE METHOD /Utente/antonio HTTP/1.1 header + payload METHOD /Messaggio/157 HTTP/1.1 header + payload

9 Un Servizio Meteo Progettazione: pensare ai metodi: ad es. gettemperatura(citta); Sviluppo: Client: utilizzo di Stub WS; Server: implementazione di Skeleton WS; Strumenti: Axis2: Container per Apache Tomcat; Client stub Motore SOAP Motore SOAP skeleton W eb Server GET /Axis2/ServiziMeteo/getTemperatura?citta=napoli

10 Una Risorsa Meteo Progettazione: pensare alle risorse: ad es. Temperatura; Sviluppo: Client: richieste HTTP; Server: risposte ai metodi HTTP; Strumenti: Un Server HTTP (per es. una classe Java); Richiesta HTTP Client Risposta HTTP W eb Server Gestione dei Metodi HTTP sulle risorse GET /Meteo/Europa/Italia/Campania/Napoli

11 Conclusioni REST: paradigma per lo sviluppo di applicazioni Web Basato su HTTP: ne eredita semplicità e scalabilità; Fornisce un'interfaccia uniforme: lo sviluppatore utilizza sempre gli stessi metodi (GET, PUT, POST, DELETE), indipendentemente dalla risorsa gestita [riutilizzo del software]; Attualmente è difficile trovare framework e documentazioni complete; Non tutti i browser e i server gestiscono tutti i tipi di metodi HTTP; Per questo, meglio adottare soluzioni ibride.