WADe 2017-2018 (2/12) Service-based Web Application Development. REST

Dr.SabinBuragaprofs.info.uaic.ro/~busaco
Dezvoltarea aplicațiilor Web
⤄servicii Web în stil REST

„Prima calitate a stilului este claritatea.”
Aristotel

Cum pot fi accesate și procesate resursele
– date, informații, cunoștințe –
disponibile pe Web?

nevoi ale dezvoltatorilor Web
Soluții multi-platformă, slab-conectate
integrare (în timp-real) la nivel de Internet/Web
a aplicațiilor, serviciilor și sistemelor

integrare (în timp-real) la nivel de Internet/Web
a aplicațiilor, serviciilor și sistemelor
exemplificare: găsirea ofertelor de servicii,
pe baza localizării geografice a utilizatorului,
în contextul dispozitivelor mobile

datele să poată fi descrise pentru a fi „înțelese”
de calculatoare și pentru a fi interconectate facil

datele să poată fi descrise pentru a fi „înțelese”
de calculatoare și pentru a fi interconectate facil
Web “puzzles”
inter-conectarea mai multor servicii oferind date de
interes, conform preferințelor utilizatorului

Servicii atașabile (pluggable) & versatile
Software as a Service – SaaS
Application Service Provider – ASP

soluție
Divizarea aplicațiilor în servicii – independente –
care se pot compune,
menite a se conecta și orchestra în mod spontan
în cadrul proceselor de afaceri/tehnice
Web component-based software

soluție
“The Web is the computer”
disponibilitatea unei/unor arhitecturi care…
oferă suport pentru paradigme de comunicare
– bazată pe actualele tehnologii Web –
între aplicații eterogene

soluție
permit(e) localizarea transparentă a serviciilor

soluție
facilitează adăugarea, înlocuirea, eliminarea
serviciilor în mod dinamic

soluție
ascund(e) dezvoltatorului detaliile de sistem

soluție
asigură calitatea dezvoltării și exploatării
aplicațiilor distribuite și/sau paralele:
standardizare, securitate, disponibilitate,
reutilizare, mentenanță etc.

Ce sunt serviciile Web?

servicii web
“A service is an abstract resource that represents
a capability of performing tasks that form
a coherent functionality from the point of view of
providers entities and requesters entities.”
www.w3.org/TR/ws-gloss/

servicii web
“A Web service is a software system designed
to support interoperable machine-to-machine
interaction over a network.”
www.w3.org/TR/ws-gloss/

servicii web
Software oferind o funcționalitate specifică
acces la resurse – Instagram, Pinterest, Slideshare, Vimeo
agregare de știri – Feedly, Reddit
cartografiere – Google Maps, Nokia HERE, OpenStreetMap
mesagerie instantanee – Snapchat, Telegram, Twilio
procesări – IBM Watson, TensorFlow, Skyttle,…
realizare de statistici Web – e.g., Google Analytics
rețele sociale – Facebook Open Graph, Twitter
spelling checking – Bing Spell Check, xSpell,…
stocare de date – Amazon S3, Dropbox, OneDrive etc.
…

servicii web
utilizate – la distanță –
de alte aplicații/servicii

servicii web
Accesate standardizat via Web
adresare de resurse cu URI
transfer de date via HTTP
mesaje adoptând formate de date: CSV, JSON, XML,…

Cum am implementa un serviciu?

servicii web
Implementare standard
recurgerea la servere + framework-uri de aplicații Web
ASP.NET, Django, Node.js,
PHP (CodeIgnater, Laravel,…),
Play!, Ruby on Rails,…

servicii web
Tradițional, aplicația oferă o interfață-utilizator
disponibilă pe Web
limbaj de marcare – e.g., HTML
stiluri de prezentare a conținutului – CSS
interactivitate via JavaScript (+biblioteci/framework-uri)

servicii web
disponibilă pe Web
cererile sunt capt(ur)ate via formulare
+ legături hipertext

servicii web
disponibilă pe Web
utilizatorii umani trebuie să interpreteze etichetele
și câmpurile de dialog

servicii web
disponibilă pe Web
serviciul implementat oferă un răspuns
(o reprezentare a unei resurse Web)
uzual, un document HTML al cărui conținut
e transferat la client conform unui protocol: HTTP(S)

servicii web
Cum obținem răspunsul pentru a fi (re)folosit
în programele noastre?
procesarea datelor din codul HTMLWeb scraping
<div class="ct-cs"><input id="exchange_rate" value="4.4155770975" type="hidden">
<input id="fob.log_input_ct" value="" type="hidden">…<table>…</table></div>

servicii web
Cum obținem răspunsul pentru a fi (re)folosit
în programele noastre?
orice modificare în marcajerescrierea programului
de preluare a datelor din documentul HTML
???!

servicii web: caracterizare
Serviciile Web fac explicite specificațiile implicite
datele de intrare și răspunsul pot fi specificate (riguros)
via diverse maniere de validare

Utilizate la interacțiunea dintre aplicații
dinamice
lipsa unei cunoașteri a-priori a interacțiunii
cu alte aplicații/servicii Web

Puncte finale utilizate pentru procesarea datelor,
în manieră publică – eventual, via API-uri deschise

Dezvoltate pe baza platformelor, arhitecturilor,
tehnologiilor și limbajelor curente

Există un model arhitectural de dezvoltare
a serviciilor la nivel de Web?

soa
Arhitectura orientată spre servicii
SOA – Service Oriented Architecture

soa
Stil arhitectural de proiectare și dezvoltare
de aplicații considerate drept servicii
care pot fi invocate de alte aplicații

soa
Paradigmă de dezvoltare a software-ului
care adoptă folosirea de servicii,
oferind funcționalități solicitate de utilizatori
resursele sunt disponibile via o suită de servicii
independente ale căror implementări
nu trebuie să fie cunoscute (black box)

soa
Componentele sistemului în ansamblu
au un grad mare de independență (de-coupling)
serviciile trebuie proiectate să interacționeze
fără a exista dependențe între acestea

soa
Serviciile partajează un contract formal
necesitatea unei descrieri formale a serviciului:
operații oferite (interfața serviciului)
maniera de interschimb a datelor (cerere + răspuns)
maniera de descoperire (service discoverability)
calitatea unui serviciu (SLA – service-level agreement)

soa
Serviciile pot fi recompuse/orchestrate
conform cerințelor sau contextului de exploatare
composable services
reusable services

soa
Serviciile nu vor depinde de starea comunicării
(statelessness)
pentru a efectua o procesare, cantitatea de informație
ce trebuie reținută trebuie să fie minimală

soa
de la aplicații Web dezvoltate tradițional
la arhitecturi bazate pe servicii
Jay O’Connor (2014)
http://tinyurl.com/l62tjab

exemplu autohton: proiectul ubiGuide – 2014
(Ionuț Dănilă & Mihaela Ghimiciu, absolvenți FII)
servicii publice folosite: ABBYY Cloud OCR, AlchemyAPI,
Google Places API, YouTube API,…
biblioteci: Flickr.NET, GART (Geo Augmented Reality Toolkit),
Hammock, TweetSharp etc.
www.youtube.com/watch?v=wygXE6hQ07c
www.slideshare.net/ionutdanila/ubi-guide

structura conceptuală stratificată a unei platforme
bazate pe servicii Web
protocoale (HTTP, SMTP,…)
servicii de regăsire: UDDI
descrieri de servicii: WSDL
context al serviciului (cine, de ce,…)
servicii de bază (calendar, tranzacții,…)
sist. tradiționale
server(e) backend
API
workflow engine
mașină virtuală
micro-/macro-serv.
ofertant/utilizator de servicii Web

Există o modalitate pragmatică privind
dezvoltarea și invocarea serviciilor Web?

rest
serviciile Web pot fi dezvoltate via SOAP și/sau REST
S. Tilkov, REST: Not an Intro (2013)
speakerdeck.com/stilkov/rest-not-an-intro-1
service interface
service logic
business rules
data access
data
resources
hypermedia
represen-
tations:
JSON, XML,…
HTTP
operations
SOAP
XML
messages
WS-*

rest: representational state transfer
Stil arhitectural de dezvoltare a aplicațiilor Web
cu focalizare asupra reprezentării datelor
teză de doctorat – Roy Fielding (2000)

rest
Viziune complementară de implementare și
utilizare a serviciilor Web – fără SOAP
SOAP
Envelope
SOAP Header
bloc antet
bloc antet
SOAP Body
bloc corp
bloc corp
bloc corp
bloc corp

rest
Rezultatul unei procesări conduce la obținerea
unei reprezentări a unei resurse

rest
resursă Web
utilizator având cont în cadrul unui sistem,
blog-ul unei persoane, fotografie, flux de știri, program,…

rest
reprezentare pe baza unui format de date
textual sau binar
exemple tipice: HTML, JSON, PNG, SVG, PDF etc.

rest
reprezentare pe baza unui format de date
formatul reprezentării e desemnat de tipuri MIME
text/html, application/json, application/rdf+xml, image/png
detalii în N.Freed et al., Media Types, 2017
www.iana.org/assignments/media-types/media-types.xhtml

rest
reprezentările aceleași resurse
– desemnate de un URI unic – pot fi multiple
reprezentare1
(HTML)
reprezentare2
(Atom)
resursa
URI

rest
fiecare reprezentare a unei resurse are asociat un URL
reprezentare1
(HTML)
reprezentare2
(Atom)
resursa
URI
URLURL

rest
Clienții (e.g., navigatoare Web, roboți, player-e etc.)
interacționează cu reprezentările resurselor via verbe
„accesează”: GET, „modifică”: POST, „șterge”: DELETE,…
reprezentare1
(HTML)
reprezentare2
(Atom)
resursa
URI
URLURL
GET POST GET DELETE

rest
Verbele (acțiunile) sunt stipulate de un protocol

rest
HyperText Transfer Protocol
protocol fiabil, de tip cerere/răspuns
port standard de acces: 80
https://profs.info.uaic.ro/~busaco/teach/courses/web/web-film.html#week2

rest
HTTP/1.1
standard Internet: RFC 2616 (1999)
din 2014, definit de RFC 7230—7235
www.w3.org/Protocols/
un tutorial: www.code-maze.com/http-series/

rest
HTTP/2.0
RFC 7540 (2015)
focalizat asupra performanței
http2.github.io

rest
HTTP/2.0
mesaje binare
reutilizarea conexiunii TCP
multiplexare
compresia anteturilor – HPACK
trimiterea mesajelor spre client (server push)
implementări: github.com/http2/http2-spec/wiki/Implementations

rest
GET
accesează (preia) o reprezentare a unei resurse
nu conduce la modificarea stării serverului – safe
idempotentă – cereri identice vor conduce la oferirea
aceluiași răspuns (aceeași reprezentare)

rest
HEAD
similară cu GET, dar furnizează doar meta-date
(nu oferă reprezentarea propriu-zisă)
e.g., ultima actualizare, lungimea conținutului,…

rest
PUT
înlocuiește (actualizează) o reprezentare de resursă sau
eventual creează o resursă la nivel de server Web
(al cărei URI e deja cunoscut)
uzual, returnează URI-ul resursei
nu e considerată safe, dar este idempotentă

rest
PATCH
permite actualizarea parțială a unei reprezentări
a unei resurse (PUT nu oferă o asemenea facilitate)
nu este safe și nici idempotentă

rest
POST
creează o resursă (uzual, subordonată altei resurse)
opțional, pot fi realizate procesări suplimentare
nu este nici safe, nici idempotentă
clientul nu cunoaște a-priori
care va fi URI-ul resursei ce va fi create

rest
DELETE
șterge (elimină) o resursă desemnată de un URI
este idempotentă

rest
OPTIONS
permite clientului să determine diverse cerințe privitoare
la o resursă (e.g., dacă o resursă poate fi ștearsă)
sau facilitățile expuse de un server
(de exemplu, suportul oferit de un proxy)

GET /sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org
&query=SELECT+DISTINCT+%3Fclass%0D%0A
WHERE+%7B%0D%0A++%3Fclass+a+owl%3AClass%0D%0A
%7D+LIMIT+7&format=application%2Fjson&timeout=30000 HTTP/1.1
Host: dbpedia.org
User-Agent: Mozilla/5.0 … Gecko/20100101 …
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en,en-GB;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://dbpedia.org/sparql
Connection: keep-alive
URL
encoding
câmpuri-antet
și valorile lor
un mesaj HTTP de tip cerere (request) trimis de client
(uzual, un browser Web) spre server
aici, o cerere încapsulând o interogare SPARQL către DBpedia

HTTP/1.1 200 OK
Date: Fri, 06 Oct 2017 07:03:52 GMT
Content-Type: application/json
Content-Length: 691
Connection: keep-alive
Server: Virtuoso/07.20.3224 (Linux) i686-generic-linux-glibc212-64
X-SPARQL-default-graph: http://dbpedia.org
Expires: Fri, 13 Oct 2017 07:03:52 GMT
Cache-Control: max-age=604800
…
{ "head": { "link": [], "vars": ["class"] },
"results": { "distinct": false, "ordered": true, "bindings": [
{ "class": { "type": "uri",
"value": "http://dbpedia.org/ontology/Place" }},… ]
} }
un mesaj HTTP de tip răspuns (response) de la server
aici, în format JSON
tipul MIME al
reprezentării oferite
câmp-antet
nestandardizat
meta-dateconținut(date)

rest
Orice accesare a unei reprezentări
plasează aplicația – ori clientul Web – într-o stare
ce va fi schimbată în urma unui transfer de date
(accesarea altei reprezentări)

resursa1
reprezentare1
(HTML)
http://blog.info/
resursa2
reprezentare2
(HTML)
http://blog.info/mesaj
resursa3
reprezentare3
(HTML)
http://blog.info/mesaj/edit
resursa4
reprezentare4
(Atom)
http://blog.info/stiri.xml
GET
GET
POST

resursa1
reprezentare1
(HTML)
http://blog.info/
resursa2
reprezentare2
(HTML)
http://blog.info/mesaj
resursa3
reprezentare3
(HTML)
http://blog.info/mesaj/edit
resursa4
reprezentare4
(Atom)
http://blog.info/stiri.xml
GET
GET
POST
HATEOAS (Hypermedia As The Engine Of Application State)

rest
Transferul se realizează prin protocolul HTTP
Reprezentarea este modelată conform unui format
– e.g., JSON sau XML – și
indicată prin tipuri MIME (media types)
Adresabilitatea se rezolvă via URI

rest
Aplicațiile care invocă funcționalități (servicii)
consumă reprezentări de resurse – în stilul pull

rest
Fiecare cerere este considerată independentă,
fără a se lua în considerație contextul
stateless server

rest
Reprezentările de resurse pot fi stocate temporar
caching

statelessserver
client
cache
client
cache
adaptare după B. Mulloy (2012)

statelessserver
client
cache
client
cache
fiecare cerere trebuie să conțină toate
informațiile necesare procesării

statelessserver
client
cache
client
cache
contextul activităților
nu-i stocat de server

statelessserver
client
cache
client
cache
clientul are dreptul să
reutilizeze datele recepționate

rest
Aplicația Web dezvoltată va fi stratificată
layered system

client
state-
less
server
state-
less
server
state-
less
server
load
balan
cer
gatewayfire-
wall

client
state-
less
server
state-
less
server
state-
less
server
load
balan
cer
gatewayfire-
wall
fiecare strat oferă
servicii stratelor
vecine

client
state-
less
server
state-
less
server
state-
less
server
load
balan
cer
gatewayfire-
wall
un strat nu poate
„vedea” strate
neînvecinate

client
state-
less
server
state-
less
server
state-
less
server
load
balan
cer
gatewayfire-
wall
stratele pot încapsula
(„ascunde”) sisteme
tradiționale – black box

client
state-
less
server
state-
less
server
state-
less
server
load
balan
cer
gatewayfire-
wall
are rol în asigurarea
performanței/
fiabilității

rest: exemplu
Serviciu pentru managementul adreselor Web favorite
(bookmark-uri), cu posibilitatea atașării de
termeni de conținut (tag-uri) și comentarii
social bookmarking
abordări similare: Delicious, Digg, Pocket, Reddit etc.

rest: exemplu
Serviciu pentru managementul adreselor Web favorite
(bookmark-uri), cu posibilitatea atașării de
termeni de conținut (tag-uri) și comentarii
funcționalitate de bază: listarea tuturor bookmark-urilor
(eventual, filtrate după diverse criterii)
managementul bookmark-urilor:
adăugare, editare, ștergere, partajare

Resursa URL Metoda Reprezentare
Bookmark /bookmarks/{hash} GET application/bookmark+xml
Bookmark /bookmarks/{hash} PUT application/bookmark+xml
Bookmark /bookmarks/{hash} DELETE
Lista de
adrese
/bookmarks GET application/atom+xml
Lista de
utilizatori
/users GET application/atom+xml
Lista de
tag-uri
/tags GET application/atom+xml
Pagina
principală
/ GET application/xml

GET /bookmarks
200 OK
Content-type: application/atom+xml
<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Bookmarks</title>
<entry>
<title>O resursă interesantă</title>
<link
href="/bookmarks/a211528f…bdcf"/>
<summary>
http://undeva.info/o-resursa-interesanta
</summary>
</entry>

</feed>
răspuns XML (Atom)
oferit de serviciu
obținerea
bookmark-urilor
digest – hash
(SHA-1, SHA-3,…)

GET /bookmarks/a211528f…bdcf
200 OK
Content-type: application/bookmark+xml
<bookmark>
<title>O resursă interesantă</title>
<url>http://undeva.info/o-resursa-interesanta</url>
<user href="/users/tux">tux</user>
<tags>
<tag href="/tags/interesting">interesting</tag>
<tag href="/tags/penguin">penguin</tag>
</tags>
</bookmark>
preluarea unui bookmark:
răspunsul XML oferit de serviciul Web

POST /bookmarks
…
201 Created
Location: /bookmarks/a211528f…bdcf
PUT /bookmarks/a211528f…bdcf
…
200 OK
crearea
unui bookmark
înlocuirea
unui bookmark

rest
Resursele se denumesc folosind URI-uri (URL-uri)
Reprezentările sunt interconectate prin URL-uri
Pot exista intermediari (proxy, cache, porți)
între clienți și resurseperformanță, securitate,...
Transferul de date poate fi și asincron – stil Ajax/Comet

O resursă poate avea asociate reprezentări
ce pot fi accesate/alterate via operații HTTP
CRUD – Create, Retrieve, Update, Delete
Operation SQL HTTP
Create INSERT PUT POST
Read (Retrieve) SELECT GET
Update (Modify) UPDATE PUT POST PATCH
Delete (Destroy) DELETE DELETE

Putem adopta o metodologie vizând
dezvoltarea de servicii Web (API-uri)
aliniate paradigmei REST?

rest: metodologie
Divizarea datelor problemei în categorii
clase tipice de resurse:
Utilizatori
Documente – alternative: Fotografii, Produse, Software,…
Metadate – e.g., Comentarii, Formate, Locatii, Platforme etc.

rest: metodologie
Divizarea datelor problemei în categorii
cazuri concrete:
SoundCloud – apigee.com/resources/soundcloud
Tracks Users Me Playlists Groups Comments
StackExchange – apigee.com/resources/stackexchange
Answers Badges Comments Questions Revisions Tags Users
World of Warcraft – apigee.com/resources/wow
Characters Guilds Realms Auctions Items

rest: metodologie
„Numirea” prin URI a fiecărei resurse
exemplificări:
http://aplicatie.info/Utilizatori/tux
http://aplicatie.info/Documente/pinguini-cu-mere-albastre

rest: metodologie
„Numirea” prin URI a fiecărei resurse
cazuri concrete:
accesarea datelor despre o producție cinematografică
http://www.imdb.com/title/tt0401383/
acces la prezentările Slideshare ale utilizatorului busaco
http://www.slideshare.net/busaco/presentations
obținerea listei celor ce urmăresc un utilizator autentificat
http://twitter.com/followers

rest: metodologie
Organizarea resurselor
aceste resurse (object instances) pot fi organizate
în colecții (collections) sau depozite (stores)
a se consulta D. Denicola, Creating Truly RESTful APIs (2013)
www.slideshare.net/domenicdenicola/creating-truly-res-tful-apis

rest: metodologie
colecție
catalog de resurse gestionate de server
clienții pot propune alterarea colecției
serverul decide care-i rezultatul unei operații
exemple (GitHub): /orgs/openstack/repos, /orgs/openstack/events

rest: metodologie
depozit
„rezervă” de resurse gestionată de client
(inclusiv filtrare, sortare, paginare, accesare meta-date,…)
exemplu (GitHub): /users/openstack/repos?page=2&per_page=3

rest: metodologie
Proiectarea reprezentării(lor) acceptate
ce pot fi trimise de aplicația client
și reprezentării(lor) întoarse spre client
de considerat formate standard
HTML, Atom, CSV, JSON(-LD), XML

rest: metodologie
Integrarea resurselor
via legături hipertext + formulare
exemplificare (GitHub):
“All resources may have one or more *_url properties
linking to other resources. These are meant to provide
explicit URLs so that proper API clients don’t need
to construct URLs on their own.”
https://developer.github.com/v3/#hypermedia

rest: metodologie
Crearea de studii de caz
specificarea condițiilor de eroare și/sau de excepție,
inclusiv aspecte privind controlul versiunilor API-ului

StrongLoop API (IBM)
operații cu resurse specifice – aici Users

StrongLoop API
testarea interactivă a API-ului
strongloop.com/strongblog/node-js-rest-api-openshift-redhat/

Aspecte practice de interes
pentru dezvoltatori?

rest: privire pragmatică
URL-urile desemnând resurse (concepte)
de interes trebuie să fie simple și intuitive
utilizarea substantivelor pentru fiecare „lucru”
colecții de resurse (uzual, la plural)
/students
identificatori unici pentru membrii unei colecții
/students/tuxy (concret) vs. /students/69 (abstract)

URL-urile desemnând resurse (concepte)
de interes trebuie să fie simple și intuitive
structura ierarhică a URL-urilor reprezintă ierarhia
resurselor din cadrul domeniului modelat
exemplu (GitHub):
/repos/Microsoft/PTVS/commits/e95e15…7a3bf91baff88

Folosirea verbelor (metodelor) HTTP pentru efectuarea
de operații asupra unor (colecții de) resurse
resursa
(URI)
POST
(creează)
GET
(accesează)
PUT
(actualizează)
DELETE
(șterge)
/students
creează
un student nou
listează studenții
existenți
actualizează
un set de studenți
șterge toți
studenții
/students/69
(un URL deja
existent)
eroare 🙁
oferă date
despre student
dacă există,
actualizează,
altfel eroare
șterge
studentul
respectiv

Tratarea erorilor
folosirea codurilor de stare HTTP – httpstatuses.com
exemple tipice:
200 OK, 204 No Content, 206 Partial Content
303 See Other, 304 Not Modified
400 Bad Request, 401 Unauthorized, 403 Forbidden,
404 Not Found, 405 Method Not Allowed
500 Internal Server Error, 503 Service Unavailable

Tratarea erorilor
mesajele returnate trebuie să includă informații utile
exemplu (GitHub): cod de stare HTTP întors – 404
{
"message": "Not Found",
"documentation_url": "https://developer.github.com/v3"
}

Controlul versiunilor API-ului dezvoltat
“Never release an API without a version
and make the version mandatory.” (Mulloy, 2012)

Controlul versiunilor API-ului dezvoltat
“Never release an API without a version
and make the version mandatory.” (Mulloy, 2012)
specificarea versiunii
în antetul HTTP vs. în cadrul URL-ului
https://api.foursquare.com/v2/venues/explore
https://api.twitter.com/1.1/statuses/
http://world.openfoodfacts.org/api/v0/product/0646809521249

Paginarea și oferirea de răspunsuri parțiale
de obicei, se folosesc parametri precum limit și offset
/students?limit=33&offset=54
filtrele opționale pot fi delimitate de virgulă
/students?fields=name,age,year,email

interogări interactive asupra API-ului
oferit de The New York Times
developer.nytimes.com

răspuns în
format JSON
diverse (meta-)date
oferite de serverul Web

Eterogenitatea formatelor reprezentărilor întoarse
indicarea formatului în URL via un parametru opțional
?alt=json (Google Data)
specificarea formatului acceptat în antetul cererii HTTP
Accept: application/json (Digg)
precizarea formatului în numele resursei solicitate
/venue.json (Foursquare)

Utilizarea subdomeniilor pentru API-uri diferite
ale aceluiași ofertant de servicii
exemplificare:
search.twitter.com
stream.twitter.com
api.twitter.com

Cum pot fi accesate
reprezentări de resurse Web prin REST?

rest: implementare
Biblioteci/API-uri implementând HTTP
libcURL (C; portări Perl, PHP, Ruby,…): curl.haxx.se/libcurl/
Apache HttpComponents (Java): http://hc.apache.org/
http (pachet Go): http://golang.org/pkg/net/http/
httplib (Python 2) + http.client (Python 3)
neon (bibliotecă C): http://www.webdav.org/neon/
rest (Node.js): https://www.npmjs.org/package/rest
RestKit (macOS + iOS): https://github.com/RestKit/RestKit
RestSharp (pentru .NET): http://restsharp.org/

rest: implementare
Studiu de caz:
accesarea datelor publice privitoare
la universul fictiv „Războiul stelelor”
colecții de resurse:
Planets, Spaceships, Vehicles, People, Films, Species
fiecare categorie de resurse are proprietăți specifice
e.g., orice instanță de Films include title, director, characters,…

rest: implementare
detalii la https://swapi.co/documentation
{
"name": "Leia Organa",
"height": "150",
"mass": "49",
"hair_color": "brown",
"skin_color": "light",
"eye_color": "brown",
"birth_year": "19BBY",
"gender": "female",
"homeworld": "http://swapi.co/api/planets/2/",
"films": [ "http://swapi.co/api/films/6/",… ],
"species": [ "http://swapi.co/api/species/1/" ],
"vehicles": [
"http://swapi.co/api/vehicles/30/" ],
"starships": [ ],
"created": "2014-12-10T15:20:09.791000Z",
"edited": "2014-12-20T21:17:50.315000Z",
"url": "http://swapi.co/api/people/5/"
}
răspuns
disponibil
în format
JSON

rest: implementare
Biblioteci/API-uri implementând HTTP
permit dezvoltarea de aplicații desktop, mobile etc.
suport pentru crearea de aplicatii hibride (mash-up-uri)
la nivel de server
nu funcționează în navigatorul Web
atenție la problemele de securitate ce pot apărea!

rest: implementare
Navigatoarele Web actuale
nu necesită un API distinct pentru acces via HTTP
disponibilitate pe orice platformă
suport pentru REST prin obiectul XMLHttpRequest (Ajax),
Fetch API (HTML5) ori WebSocket API (HTML5)

rest: dezvoltare – exemplificări
ASP.NET MVC + Web API (C# et al.): www.asp.net/web-api
APIconnect, Express, Restify, webservice (Node.js)
https://nodejsmodules.org/tags/rest
JAX-RS – Java Architecture for RESTful Services
https://jax-rs-spec.java.net/
Restlet (Java): https://restlet.com/projects/restlet-framework/
Cornice, Django, Eve, Pecan (Python)
Grape, RESTRack, Ruby on Rails (Ruby)
www.ruby-toolbox.com/categories/API_Builders
Fat-Free, Slim (micro-framework-uri PHP)

rest: dezvoltare
Servicii publice ce pot fi consumate via REST – exemple:
500px, AIDSInfo, Amazon, Basecamp, Blip.tv, DBpedia,
eBay, Ericsson, Facebook, GitHub, Google, LinkedIn,
Mastercard, Nodejitsu, Pipl, Quora, SlideShare, Tumblr,…
de explorat ProgrammableWeb
www.programmableweb.com/category/all/apis

În cazul aplicațiilor Web sociale,
putea utiliza servicii Web
pentru autorizare și autentificare?

rest: dezvoltare
Pași uzuali de urmat pentru implementarea unei aplicații
ce va invoca un serviciu Web pe baza unui API public:
(1) înregistrarea aplicației concepute
via situl entității furnizoare a serviciului
cheie de acces – API key, consumer key, developer key

rest: dezvoltare
(2) pe baza acestei chei, aplicația se va putea autentifica
pentru a putea fi autorizată să acceseze serviciul

rest: dezvoltare
(2) pe baza acestei chei, aplicația se va putea autentifica
pentru a putea fi autorizată să acceseze serviciul
pot fi impuse diverse politici de acces (permissions):
doar consultare (read), posibilitatea editării etc.
a se studia și inițiativa Open Credentials: opencreds.org

rest: dezvoltare
(3) autentificarea și autorizarea aplicației
au loc cu acordul utilizatorului

rest: dezvoltare
(3) autentificarea și autorizarea aplicației
au loc cu acordul utilizatorului
dacă utilizatorul nu este autentificat, i se vor solicita
informațiile de autentificare (e.g., nume + parola)
– eventual, folosind 2FA (Two Factor Auth) –,
apoi va putea autoriza aplicația să aibă acces la date
via serviciul Web furnizat

rest: dezvoltare
autentificare multi-factor (2FA): twofactorauth.org

rest: dezvoltare
(4) aplicația apelează funcționalitățile oferite de serviciu
pentru preluarea/modificarea datelor de interes,
conform politicilor de acces

rest: dezvoltare
(4) aplicația apelează funcționalitățile oferite de serviciu
sesiunea curentă va fi stabilită și menținută
pe baza unor informații de autentificare (auth tokens)

rest: dezvoltare – oauth
Autorizarea unei aplicații să acceseze date private
într-un mod standardizat – pe baza tehnologiilor
Web actuale – se poate realiza via OAuth

Autorizarea unei aplicații să acceseze date private
într-un mod standardizat – pe baza tehnologiilor
Web actuale – se poate realiza via OAuth
protocol deschis – RFC 6749
OAuth 1.0 (2010), OAuth 2.0 (2012)
http://oauth.net/2/

securitatea datelor
procesele de autorizare a accesului la o resursă Web
conform Dominik Mengelt (2013)

securitatea datelor
exemplu concret – Facebook:
autorizare cu diverse permisiuni – e.g., age_range,
email (acces la adresa de e-mail a unui utilizator),
public_profile, user_birthday, user_hometown, user_friends,
user_likes, user_photos, rsvp_event și altele
developers.facebook.com/docs/facebook-login/permissions/v2.0

Biblioteci (server și/sau client) disponibile pentru
C, C++, Go, Erlang, Java, JavaScript, Objective-C, .NET,
Perl, PHP, Python, Ruby, Swift,…
http://oauth.net/code/
Servicii proxy de autentificare/autorizare prin OAuth:
Auth0 – auth0.com
Hydra – github.com/ory/hydra
OAuth – oauth.io
Okta – developer.okta.com

exemplificare: hello.js – soluție modulară,
la nivel de client, vizând autentificarea și
accesarea serviciilor Web via REST
adodson.com/hello.js/

Autentificare via servicii Web specifice – exemple:
GitHub – developer.github.com/v3/oauth/
Google – developers.google.com/identity/protocols/OAuth2
LinkedIn – developer.linkedin.com/docs/oauth2
Live Connect (Microsoft) – http://tinyurl.com/zztr97h
Pinterest – developers.pinterest.com/docs/api/overview/
Stack Exchange – api.stackexchange.com/docs/authentication
Twitter – dev.twitter.com/oauth
WordPress – developer.wordpress.com/docs/oauth2/

rest: dezvoltare – openid
de experimentat accesul la diverse date (e.g., persoane de contact
via Google Contacts API) pe baza OAuth 2.0 Playground
developers.google.com/oauthplayground/

OpenID
manieră descentralizată de autentificare a utilizatorului
la nivel de Web pe baza paradigmei SSO – Single Sign On
utilizatorul poate demonstra că deține un URL specific
menit a-l identifica on-line via un ofertant (serviciu)
de identitate digitală (identity provider)
e.g., folosind o aplicație Web socială

Fiecare identitate a unui utilizator e desemnată de un URL
(stabilit de identity provider)
exemplu: steamcommunity.com/openid/id/steamid
pentru a-și confirma identitatea,
utilizatorul va trebui să se autentifice:
nume de cont + parolă, smart card, date biometrice,…

OpenID
biblioteci open source disponibile
pentru C, C#, Java, JavaScript, PHP, Python, Ruby,…
http://openid.net/developers/libraries/

OpenID Connect
oferă un nivel vizând identitatea utilizatorului
(identity layer) pe baza protocolului OAuth 2
recurge la formatul JWT (JSON Web Token)
standardizat în RFC 7519 (2015)
openid.net/connect/

OpenID Connect
biblioteci open source disponibile pentru C, C#, Java,
JavaScript, PHP, Python, Ruby, TypeScript,…
openid.net/developers/libraries/
suport oferit de serverul Web:
mod_auth_openidc – modul Apache
github.com/pingidentity/mod_auth_openidc
L. Crilly, Authenticating API Clients with JWT (2016)
www.nginx.com/blog/authenticating-api-clients-jwt-nginx-plus/

Mesaje – de autentificare sau
interschimb de informații –
vehiculate în format JWT
resurse de interes + instrumente
oferite de jwt.io
jeton JWT

rezumat
⤄aplicații orientate spre servicii Web în stilul REST
aspecte vizând autorizarea și autentificarea

episodul viitor: arhitectura aplicațiilor Web
de la API-uri și mashup-uri la proiectare arhitecturală

WADe 2017-2018 (2/12) Service-based Web Application Development. REST

Recommended

Recommended

More Related Content

What's hot

What's hot (13)

Similar to WADe 2017-2018 (2/12) Service-based Web Application Development. REST

Similar to WADe 2017-2018 (2/12) Service-based Web Application Development. REST (18)

More from Sabin Buraga

More from Sabin Buraga (20)

WADe 2017-2018 (2/12) Service-based Web Application Development. REST