Distribuirani sustavi REST Bojan imunovi Darko Majki Ivan

Distribuirani sustavi REST Bojan Šimunović Darko Majkić Ivan Sušanj Mentor: mr. sc. Kaluža Marin, viši predavač

Web servisi Tehnologija za izgradnju DRS-a Prednost WS-a : ne ovise o arhitekturi računala Dominantan način komuniciranja na internetu Tri grupe (ovisno o načinu komuniciranja) : SOAP, POX/HTTP, REpresentational State Transfer

REST (1) Dr. Roy Fielding Jedan od osnovnih autora HTTP-a i URI-a Misao vodilja : “REST je namjenjen da prikaže sliku kako se dobro dizajnirana web aplikacija ponaša. . . ” Najvažniji principi/ograničenja : Identifikacija resursa Manipulacija resursa kroz reprezentaciju Samo-opisne poruke Hipermedija kao pokretač aplikacijskog stanja (HATEOAS)

REST (2) Izgradbeni blokovi Web-a HTTP metode

Ograničenja REST-a Client – Server Odvojenost klijenta od servera jednoznačnim interface-om, pa su i zaduženja odvojena Stateless Komunikacija između klijenta i servera se odvija bez postojanja stanja Caching Spremanje podataka u predmemoriju ovisno o oznaci Prednost: poboljšavanje učinkovotosti, skalabilnost. . . Uniform interface Glavno svojstvo po kojm se REST razlikuje od ostalih “modela” HATEOAS URL i HTML sadrže stanje sjednice Layered components Svaka komponenta u interakciji zahtjeva je neovisna od bilo koje druge

Statistički prikaz korištenja REST-a

Sigurnost REST-a REST-u nedostaje sigurnosni model Osjetljiv na razne vrste napada (INJECTION, XSS, CSRF, BROKEN AUTHENTICATION) Savjeti developerima Ne postavljajte sami sigurnost svojih API-a Ne koristite jednostavnu autentifikaciju Ne koristite nekriptirane ključeve Koristite HMAC, izbjegavajte SHA i MD 5 Poželjno bi bilo da REST klijent koristi SSL

SOAP Standardizirani protokol XML za razmjenu poruka SOAP poruka Envelope Header Body Popis operacija Najčešće implementiran preko HTTP-a

Sadržaj SOAP poruke

SOAP i REST (1) Očuvanje stanja (sesije) REST => Stateless OAuth, Open. ID Komunikacija sa serverom GET POST PUT DELETE Pouzdanost slanja poruka

SOAP i REST (2) Zaštita podataka SOAP – WSSecurity REST – SSL (Ne)ovisnost o protokolu za komunikaciju Mapiranje CRUD operacija REST => DBMS Web-a Asinkrona komunikacija „Pretplata” na događaje (Pub/Sub)

SOAP i REST – alati za razvoj SOAP WSDL Generiranje proxy klasa Potreba za dodatnim bibliotekama REST WSDL 2. 0, WADL, HTML „Ručno” čitanje dokumentacije Jednostavnost izgradnje klijenta

REST- problemi Nekonzistentnost procesa autentifikacije Nepravilnosti kod korištenja HTTP operacija Nepravilnosti kod korištenja HTTP statusnih kodova Nepravilnost u povratnim porukama

REST i SOA (1) Otkrivanje sučelja prema resursima kod SOA dekompozicije Ispravno ili pogrešno? Prednosti na klijentu i serveru Potreba za složenim procesom mapiranja resursa Temeljni ciljevi SOA => Strateški, poslovni REST => tehnološki

RESTFul SOA Resursi podržani SOA operacijama Onemogućena direktna manipulacija resursima Različiti formati podataka Sigurnost na transportnom sloju

RESTFul SOA - primjena e. Bay Nadogradnja postojećih sustava temeljnih na servisno orijentiranoj arhitekturi Ciljevi Optimizirani SOA framework Pružiti SOAP i REST sučelje Podrška za više formata (JSON, NV, XML, RSS, ATOM) Mapiranje na postojeće SOA operacije

Stupanj implementacije REST -a

RESTful – jedino stupanj 3 API-ji još uvijek nisu u potpunosti srasli sa Fieldingovom teorijom Većinom su tek na prvoj ili drugoj stepenici prema Richardsonovome modelu

Prvi stupanj – korištenje URIjeva URI-jevi za collection resurse i instance resursa, upravljanje resursima preko reprezentacija Obično tuneliranje preko HTTP-a (korištenje GET-a i POST-a za transport) Zadovoljavajući za pozive procedura, međutim ne zadovoljava ciljeve REST arhitekture (između ostalog zbog toga što se za svaku akciju mora raditi novi URI) – dakle svodi se na RPC Ne omogućava promjene strukture URI-ja bez ogromnog utjecaja na klijente (tight coupling)

Twitter U prvom stupnju po R. Modelu – resursi i pristupanje njima organizirano na slijedeći način: GET statuses/show/: id POST statuses/destroy/: id A drugi stupanj bi podrazumijevao nešto poput GET statuses/: id DELETE statuses/: id

Drugi stupanj - korištenje HTTP metoda Zahtjev za reprezentacijom resursa - GET Kreiranje novog resursa (novi URI) – POST Modificiranje postojećeg resursa - PUT Brisanje postojećeg resursa – DELETE Dohvaćanje metapodataka o resursu - HEAD Dohvaćanje informacija o mogućim akcijama nad resursom - OPTIONS Dakle, sve akcije vezane uz jedan resurs se mogu odvijati uz pomoć samo jednog URI-ja

Statusni kodovi Uvid u stanje resursa 200 ok, 201 created, 202 accepted 301 multimple choices, 302 moved, 303 see other (preusmjeravanje) 400 bad request, 403 forbidden, 404 not found U headeru trebaju biti navedeni content – type, content-lenght, encoding i language

CRUD ima nedostataka Hipermedija ni u ovom stupnju nije uvedena, dakle još uvijek API nije samoopisujući I dalje se radi o uskom vezivanju API-ja sa klijentom (“tight coupling”)

Treći stupanj – hipermedijske kontrole Praćenje linkova uzrokuje zahtjeve i pokretanje akcija Linkovi također vode na ostale resurse koji su potrebni za akciju, dakle moguće je “kretanje” kroz API u stilu kretanja web sajtovima nepotrebni WADL, ogromne dokumentacije. . Bitne su samo ulazne točke, te definicije korištenih hipermedijskih tipova

Ulazna točka <entry> <id>2</id> <link rel = "/linkrels/entry/novikomentar" uri = "/entries/2/komentar" /> <link rel = "self" uri = "/entries/2" /> </entry>

Zaključak Popularnost REST-a raste Prikladan za izradu sučelja na API Nije dovoljno zreo za uporabu u većim sustavima Kombinacija REST-a i SOA-e, iako teorijski pogrešna, daje dobre rezultate Vrlo rijetka postojanost potpune implementacije REST-a