1

Sisteme distribuite Tehnologii

9. REST si Web 2.0
Decembrie 4, 2009
2
Representational State Transfer
Termen aparut in 2000
Stil arhitectural
O metoda de transport media utilizat in mod primar
peste WWW, dei nu este restrrictionat la acesta
Este constrit ca sistemhiper-mediaWebul este cela
mai mare
Termenul defineste principiile arhitecturale de transfer
peste sisteme,
Este orientat in special asupra transferului datelor
peste HTTP fara utilizarea unui nivel de transmitere
aditional, precumSOAP.
3
Filozofia care conduce la REST
Modalitatea de design a unui aplicatii Web:
Identificarea conceptelor sale de baza,
Modelarea lor ca resurse,
Asignarea lor de identificatori unice de resurse (URI).
Agenti software, precumnavigatoarele Web sau aplicatiile Web,solicita
aceste resurse, specificand formatul preferat de reprezentare
Serviciul Web raspunde prin reprezentarea resursei catre agent in
formatul care este cel mai apropriat de cerere.
Selectarea celei mai bune reprezentari este referita ca si negociere de
context.
Agentul trece atunci la urmatoarea stare bazandu-se pe continutul
resursei primite tipic continand hiper-linkuri la alte resurse
Hiper-linkurile sunt apoi utilizate pentru cererile urmatoare, care
cauzeaza tranzitia agentului la o stare noua
4
Prima idee de baza: hiper-link
Reprezentarea unei resurse va contine adesea
legaturi la alte resurse
Un agent va urmari aceste legaturi pentru a obtine
informatia
In context WS, aceasta inseamna ca mesajele
schimbate vor contine referinte la alte WSuri.
O descriere concreta a serviciului Web trebuie de
asemenea sa descrie interfetele acestor referinte la
alte servicii Web
5
A doua idee: interfata uniforma
Exista un set standard de verbe sau metode
care sunt utilizate pentru a accesa orice
resursa
In HTTP, metodele cela mai comunesunt
PUT, GET, POST, si DELETE, care
corsepunde cu operatiunile Create, Retrieve,
Update, si Delete (CRUD) pe baze de date
In practica, majoritatea aplicatiilor Web
utilizeaza doar GET si POST.
6
GET
Trebuie sa fie utilizat pentru operatii care sunt sigure, ceea ce
inseamna ca sunt idempotente si nu impune obligatii
Idempotenta inseamna ca rezultatul in urma efectuarii de doua
ori a operatiei este aceeasi ca si daca este efectuata odata
Exemplu: obtinerea balantei contului este idempotenta, dar
retragerea banilor nu este
O obligatie poate fi ceva precumtaxarea contuli pentru o operatie
Operatiile sigure admit anumite optimizari precumprefetching si
caching.
Exemplu: un navigator Web poate opta pentru prefetching a
paginilor legate si aplica caching la rezultatelor pentru a
imbunatati timpul de raspuns si reduce traficul de retea
7
Negocierea continutului
Mecanismul prin care agentul poate specifica tipurile de reprezentari ale resursei pe
care le prefera sa le receptioneze ca raspuns la o cerere
Exemplu: pp. un navigator Web care cere o pagina HTML.
Parte cererii este un antet HTTP Accept care listeaza tipurile de imagini care poate fi
randata de navigatorul Web, cu greutati care indica preferintele sale.
Cand aplicatia Web receptioneaza cererea,
Inspecteaza antetul Accept si
Genereaza o pagina Web pentru legaturi la tipul de imagine care se protriveste cela mai bine la
preferintele navigatorului Web.
Un mecanismsimilar poate fi utilizat pentru specificarea limbajului natural dorit la raspuns
Negocierea contextului se aplica si la servicii Web.
De exemplu
Un client AJ AX poate prefera un raspuns codat in J SON ca prima alegere, apoi XML, si in
final SOAP, deoarece aceasta este ordinea care minimizeaza timpul de parsare
Clientul include un antet Accept in cererea sa indicand ca accepta aceste tipuri media si
apoi asigneaza preferinte adecvate
Clientul AJ AX receptioneaza raspunsul in format care este mai eficient pentru a-l procesa
daca serviciul Web il ofera, dar poate totusi functiona daca serviciile Web ofera formate
acceptabile.
WSul poate fi atualizat la o data ulterioara pentru a imbunati erformanta si clientii vor
beneficia autoat de modificarile respective
8
Componentele cheie ale designului RESTful
1. Starea si functionalitatea unei aplicatii sunt
separate in resurse diferite.
2. Fiecare resursa partajeaza o metoda
consistenta pentru transferul starii intre
resurse
3. Fiecare resursa este adresabila utilizand o
sintaxa hiper-media
4. Este un protocol care este fara stare,
cacheable, bazat pe client/server, si pe
straturi.
9
World Wide Web
Este exemplul perfect pentru implementare RESTful, pentru ca
poate se poate conforma principiilor REST.
HTML
Are suport implicit pentru hiper-linkuri in limbaj
Are metode consistente (GET, POST, PUT, si DELETE) pentru
accesarea resurselor din URIuri, metode, coduri de stare, si
antete.
HTTP
Este fara stare (daca nu sunt utilizati cookies),
Are abilitatea de control a cachingului,
Utilizeaza notiunea de client si de server
Este stratificat a.i. nici un nivel nu poate cunoaste nimic despre
celalalt expectand conexiunea imediata prin conversare
10
Tringhiul REST
Interfata = verb,
Tipurile de continut
Identificator de resurse
= substantiv (noun).
REST defineste
substantivele care fiind
neconstranse a.i. clientii
nu trebuie sa cunoasca
intreaga resursa
11
SOA sau REST?
Arhitectura care este utilizata in aplicatii depind de
WSurile cu care interactioneaza
1. Daca cunoastemca unica interfata la WS este prin
SOAP, este natural ca arhitectura aplicatiei sa fie
definita ca urmarind SOA.
2. Daca WS este RESTful, construirea aplicatiei pentru a
urmari principiile REST este adecvat.
Fiecare componenta a unei aplicatii poate fi construita
intr-o modalitate, iar alta intr-o modalitate diferita
Aplicatia ca intreg orice stil arhitectural care este
necesar pt. proiect (client/server, Model-View-
Controller MVC, etc.), pe cand componentele
urmaresc propriile modele pe cat ai eficient posibil
12
Servicii Web in stil REST
Anumiti vendori, precumAmazon, ofera atat interfete SOAP cat si REST
Amazon 2003: 85 % din utilizarile WS s-au realizat prin interfata REST.
Aceasta preferinta este datorata faptului ca utilizarea principala a WS Amazon este
aceea de a oferi legaturi produs pentru pagini Web.
Interfertele in stil REST sunt mai usor de utilizat
SOAP 1.1
Majoritatea motoarelor utilizeaza un singur URL care actioneaza ca un router pentru
cererile de servicii
Motorul SOAP examineaza cererea de determinare a operatie si invoca implementarea
serviciului asociata cu acesta
SOAP 1.1 peste HTTP utilizeaza intotdeauna POST, astfel incat toate operatiile sunt
tratate ca fiind nesigure.
WSDL 1.1
Defineste toate legaturile HTTP, una pentru GET si alta pentru POST.
Aceasta inseamna ca nu se poate descrie un serviciu care are o combinatie de operatii sigure si
operatii nesigure
De asemenea nu se poate utiliza intotdeauna metoda corecta HTTP pentru orice operatie pentru
ca PUT, DELETE, nu sunt suportate.
Nu ofere nici o modalitate de a descrie mesaje care se refera la alte WSuri, adica n-are
suport pentru hiper-linking.
13
SOAP 1.1 si WSDL 1.1
Sunt ostile REST.
Aceste specificatii ofera bazele oentru o multime
mare si bogata de specificatii aditionale referite ca
WS-*.
WS-Security, WS-Reliability, si WS-Addressing sunt cateva
exemple
Modalitatea de a gandi despre WS-* este aceea de a defini
o modalitate de scurge mesajele WSurilor peste hopuri
multiple de transpot implicand o combinatie de protocoale
De exemplu, un serviciu Web de companie poate
receptiona o cerere peste HTTP si s-o plaseze intr-o coada
de mesaje
14
SOAP 1.2 si WSDL 2.0
aduce lumea WSurilor intr-o aliniere mai buna cu
principiile arhitecturii REST.
SOAP 1.2 suporta utilizarea GET pentru cereri.
WSDL 2.0
Permite descrierea operatiilor sigure
O legare HTTP imbunatatita si
Include suport pentru descrierea mesajelor care se refera
la alte WSuri;
hiper-linking intre serviciile Web pot fi descrise
La intrarea in era tehnologiilor Web 2.0, putem
vedea o unificare a stilurilor WS, WS-* si REST,
bazate pe SOAP 1.2 si WSDL 2.0.
15
Web 2.0
16
Syndication-1
Tipul de sindicat in care sectiunile dintr-un site Web
sunt facute disponibile pentru altele pentru utilizare,
majoritatea utiizand XML ca agent de transport.
News, vreme, si site-urile blog sunt intotdeauna
sursele comune pentru sindicare,
Dar nu exista o limitare de unde poate veni o alimentare
RSS este parte a unei familii de standarde care
toate utilizeaza XML pentru structura lor de baza
RDF, baza pentru RSS 1.0, este un standard W3C
17
Syndication-2
Deoarece toate versiunile diferite de RSS si problemele acestora au
creat confuzii, un alt grup a inceput sa lucreze la o specificatie noua
numita Atom.
In iulie 2005, IETF a acceptat Atom 1.0 ca si propunere de standard.
Exsita mai multe diferente majore intre Atom 1.0 si RSS 2.0.
Atom 1.0 este
Intr-un spatiu de nume XML,
Are un tip MIME inregistrat,
Include o schema XML si
S-a supus unui proces de standardizare
RSS 2.0
Nu este intr-un spatiu de nume
Este adeasa trimis ca aplicatie/rss+xml dar nu are un tip MIME inregistrat,
Nu are o schema XML si
Nu este standardizat si nu poate fi modificat.
18
XSLT
Limbaj bazat pe XML utilizat pentru a transforma si formata
documente XML.
In 1999, XSLT version 1.0 a devenit recomandare W3C.
Din 2007, XSLT version 2.0 este o recomandare care lucreaza
impreuna cu XPath 2.0.
XSLT utilizeaza XPath pentru a identifica submultimi ale arborelui
documentului XML si pentru a efectua calcule la interogare
XSLT preia un document XML si creaza un nou document cu toate
transformarile, lasand documentul original XML intact.
In context Ajax, transformarea produce in mod uzual XHTML
19
Alimentatori Web (feeds) o alta
modalitate de acces la date
Web feeds sunt documente bazate pe XML structurate cu RSS sau Atom.
Alimentatorii sunt generati in diferite modurisi sunt static prin natura
O modalitate de a crea un alimentator este de a scrie un script care viziteaza
pagini si strange date din acestea
Web scraping (strangere) nu este modalitatea cea mai nobila de colectare date si
poate incalca drepsturile de proprietate
Utilizarea unui alimentator pentru a strange informatie este o modalitate buna de
creare a WSurilor
Alimentatoarele pot fi stranse la server si diseminate la clienti cand este ceruta
informatia
Este o solutie buna pentru colectarea titlurilor si descrierilor dintr-o sursa care poate
nu ofera WSuri pentru a obtine informatia
Dezavantajul major este aflarea la dispozitia furmizorului [Ceea ce furnizorul plaseaza
in alimentator este ceea se obtine].
Feed aggregators (agregatori de alimentatori) strang alimentatorii de la
furmizorii de continut si le agregheaza intr-o modalitate mai usoara pentru a
obtine date pemtru or aplicatie
Exemplu: Google Reader, de la http://www.google.com/reader. Aplicatia preia
alimentarorii de la surse diferite (in timp real) si permite cele care subscriu sa-si
customizeze selectiile
20
Exemplu: feed de la Yahoo! Weather
(http://weather.yahooapis.com/forecastrss?p=62221)
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<rss version="2.0
xmlns:yweather="http://xml.weather.yahoo.com/ns/rss/1.0"
xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
<channel>
<title>Yahoo! Weather - Belleville, IL</title>
<link>
http://us.rd.yahoo.com/dailynews/rss/weather/Belleville_IL/*
http://weather.yahoo.com/forecast/62221_f.html </link>
<description>Yahoo! Weather for Belleville, IL</description>
<language>en-us</language>
<lastBuildDate>Tue, 13 Mar 2007 11:55 am CDT </lastBuildDate>
<ttl>60</ttl>
<yweather:location city="Belleville" region="IL" country="US" />
<yweather:units temperature="F" distance="mi" pressure="in"
speed="mph" />
<yweather:wind chill="77" direction="210" speed="14" />
<yweather:atmosphere humidity="50" visibility="1609"
pressure="30.07" rising="2" />
<yweather:astronomy sunrise="7:15 am" sunset="7:05 pm" />
<image> <title>Yahoo! Weather</title>
<width>142</width> <height>18</height>
<link>http://weather.yahoo.com/</link>
<url>http://l.yimg.com/us.yimg.com/i/us/nws/th/main_142b.gif</url>
</image>
<item>
<title>Conditions for Belleville, IL at 11:55 am CDT</title>
<geo:lat>38.5</geo:lat>
<geo:long>-90</geo:long>
<link>
http://us.rd.yahoo.com/dailynews/rss/weather/Belleville_IL/*
http://weather.yahoo.com/forecast/62221_f.html
</link>
<pubDate>Tue, 13 Mar 2007 11:55 am CDT</pubDate>
<yweather:condition text="Fair" code="34" temp="77"
date="Tue, 13 Mar 2007 11:55 am CDT" />
<description>
<![CDATA[
<img src="http://l.yimg.com/us.yimg.com/i/us/we/52/34.gif" /><br />
<b>Current Conditions:</b><br />
Fair, 77 F<BR /><BR />
<b>Forecast:</b><BR />
Tue - Partly Cloudy. High: 81 Low: 58<br />
Wed - Partly Cloudy. High: 76 Low: 55<br /> <br />
<a href="http://us.rd.yahoo.com/dailynews/rss/weather/
Belleville_IL/*
http://weather.yahoo.com/forecast/62221_f.html">
Full Forecast at Yahoo! Weather </a><BR/>
(provided by The Weather Channel)<br/> ]]>
</description>
<yweather:forecast day="Tue" date="13 Mar 2007" low="58"
high="81" text="Partly Cloudy" code="30" />
<yweather:forecast day="Wed" date="14 Mar 2007" low="55"
high="76" text="Partly Cloudy" code="30" />
<guid isPermaLink="false">62221_2007_03_13_11_55_CDT</guid>
</item>
</channel>
</rss>
21
PHP code care transforma acest alimentator intr-
un servivciu Web tip REST
<?php
/* Using feeds to distribute information with PHP.
* This example shows how to take an RSS feed and strip out the information
* desired by the application, giving only a minimal amount of data to the client.*/
/* Get the RSS feed from Yahoo! for my zip code */
$results =file_get_contents('http://weather.yahooapis.com/forecastrss?p=62221');
$xml =new SimpleXMLElement($results);
/* Create the XML for the client */
$response ='<response code="200">';
$response .='<weather>';
/* Create the prefix context for the XPath query */
$xml->registerXPathNamespace('y', 'http://xml.weather.yahoo.com/ns/rss/1.0');
/* Gather the temperature data */
$temp =$xml->xpath('//y:condition');
/* Fill in information for the client */
$response .='<temp>'.$temp[0]['text'].', '.$temp[0]['temp'].' &#176;F</temp>';
$response .='<img>'.$xml->channel->image->url.'</img>';
$response .='<link>'.$xml->channel->image->link.'</link>';
$response .='</weather>';
$response .='</response>';
/* Change the header to text/xml so that the client can use the return string as XML*/
header('Content-Type: text/xml');
/* Give the client the XML */
print($response); ?>
22
Validarea alimentatorului
1. Serviciile de validare a alimentatorilor sunt disponibile pentru a verifica
validitatea unui alimentator pentru a fi sigur ca aplicatia va lucra cu
acesta
2. Periodic verifica validitatea alimentatorului pentru a asigura ca serviciul
de agregare lucreaza
3. Sau scrie o aplicatie care realizeaza validarea alimentatorului in mod
automat
Exista un numar de validatori dintre care se poate alege:
Feed Validator (http://feedvalidator.org/) functioneaza atat pentru RSS cat si
Atom
W3C Validator (http://validator.w3.org/feed/) lucreaza in aceeasi maniera ca
validatorii W3C HTML/XHTML si CSS
Redland RSS 1.0 Validator (http://librdf.org/rss/). Valideaza si formateaza
rezultatul pentru afisare.
Experimental Online RSS 1.0 Validator
(http://www.ldodds.com/rss_validator/1.0/validator.html) utilizeaza o schema
Schematron pentru validare RSS 1.0.
RSS Validator (http://rss.scripting.com/) testeaza validitatea RSS feeds.
23
Mashup-uri & WS
Un mashup este ceea se obtine prin combinara
WSurilor
Rezultatul este o aplicatie Web 2.0 care este
mai sofisticata decat partile sale si ofera
functionalitate care nu a existat anterior
Prin combinarea WSurilor in mashupuri, se
asigura un ajutor pentru aplicatiile Web pentru a
oferi o aparitie dinamica
24
Mashup
= site Web sau aplicatie care combina doua sau mai multe surse
de informare intr-o noua aplicatie Web
Este o aplicatie Web hibrida in care parti ale aplicatiei provin din
interfete publice precumalimentatori web, scraping, si servicii
Web.
Termenul a devenit prima data popular in industria muzicii, cand
DJ din intreaga lume au inceput sa combine parti de inregsitrari
existente de muzica (cateodata de genuri diferite) pentru a crea
noi inregistrari
Prima aplicatie web publica notabila care a utilizat doua APIuri
diferite a fost lansata in Aprilie 2005: HousingMaps.com.
Prin utilizarea J avaScript de la Google folosit pentru harti si
combinarea acestuia cu site-ul calsic Craigslist, autorul a creat un
site care permite utilizatorilor sa vizualizeze cautarea de case in
majoritatea oraselor din SUA
Nu mukt dupa aceea, Google si alte motoare da cautare au
eliberat public APIurile pentru resurse lor care permite
dezvoltatorilor comunitatii web sa raspunda cu sute de mashupuri.
25
Sursa datelor exemple pentru date publice
Inregistrari precumdemografie, decese etc.
Numeroase asemenea informatii sunt contrac cost, desi
anumite agentii guvernamentale incep sa permita accesul la
anumite informatii pe gratis
Ideea ca este public poate excita mai multi dezvoltatori inainte
ca sa realizeze cu datele sunt contra cost
Exista o distinctie clara intre public si gratisnu sunt acelasi
lucru
Exemple de date disponibile public:
Inregistrari publice
Inregistrari de verificare
Inregistrari de afaceri
Cautari de persoane
26
Inregistrari publice & Inergistrari de verificare
Date publice
Exemple: inregistrari nasteri, decese, casatorii, divorturi,
faliment,
Aceste date pot fi accesate online, dar contra unei sume
Exista siteuri care permit utilizatorului sa caute date si sa
plateasca o taxa pentru a ajunge la informatii.
Exemple:
People Finders (http://www.peoplefinders.com/)
Public Record Finder (http://www.publicrecordfinder.com/)
Date de verificare
Tipic persoanele care fac verificari daca de exemplu vor sa
afle daca o anumita persoana are dosar penal
Costa mai mult accesul pentru ca este mai dificil de obtinut
27
Inregistrari de afaceri & cautari de persoane
Inregistrari de afaceri.
Date despre business (mari sau mici) sunt disponibile public.
Exemple de informatii despre o afacere: nume, proprietar,
adresa, stat, tip de taxe, informatie de completat, licente
profesionale etc
Cautare de persoane.
Stranse si mentinute de corporatii pentru scopuri de marketing
Majoritatea cautarilor de nume sau numere de telefon sunt
realizate pe baza acestor surse
Informatiile care sunt oferite:
Nume
Varsta/data nasterii
Adresa
Numar de telefon
Identificator personal (ex. CNP, numar de asigurare sociala)
Exemplu: carti de telefon online
28
Servicii open-source
Usual permit obtinerea de date care nu pot fi gasite
in alta parte pe Web, sau date care sunt disponibile
car nu sunt accesibile printr-un API.
Gasirea acestor servicii poate fi realizata pe baza
siteruilor webe care sunt dedicate pentru listarea
serviciilor Web disponibile
Lista din 2008:
Web Service List (http://www.webservicelist.com/)
WebserviceX.NET
(http://www.webservicex.net/WS/default.aspx)
Programmable Web (http://www.programmableweb.com/)
Webmashup.com(http://www.webmashup.com/)
29
Portlet pentru aplicatii
Portlet-urile sunt componente care sunt usor de
introdus si agregat intr-o pagina
O aplicatie care este compuas din trei sau mai
multe servicii Web si prortleturi care nu
intercationeaza intre ele trebuie considerata un
mashup.
Portleturile individuale includ un mashup care
este un portal de informare Web
30
Construirea unui Mashup
1. Alegerea unui subiect.
precumcombinarea de harti, date reale, fotografii, capabilitati de
cautare
decide care tip de WS este necesar
2. Selecteaza sursa datelor.
Exemplu: utilizarea datelor legate de harti care le ofera Google, si
utilizarea APIului propriu al utilizatorului.
3. Decide supra mediului de lucru si limbajului.
Prima decizie sete a limbajului care se doreste utilizat
No conteaza ce se utilizeaza, PHP, C#.NET, Perl, sau J ava, importanta
este stapanirea limbajului.
Cateodata APIul utilizat lucreaza numai pentru anumit limbaj
Un factor important este tipul de transport utilizat
Trebuie asigurata crearea conexiunilor la API si tratarea datelor care
sosesc ca raspuns, indiferent ce este utilizat SOAP, REST, sau XML-RPC.
4. Codare.