UNIVERZITET U SARAJEVU

ELEKTROTEHNIKI FAKULTET SARAJEVO

Web servisi
Baze podataka
lanovi:
Ahmetovi Emir
Hadi Alen
Hajdarevi Adnan
Halilovi Amel
Hidi Adnan
Zubanovi Damir
Sarajevo, 2013.
1


Sadraj
SOA (Service-oriented architecture) ............................................................................................... 3
Komponente ............................................................................................................................... 3
ESB (Enterprise Service Bus) ....................................................................................................... 4
Servisi ESB-a ............................................................................................................................ 5
SOA Registar ................................................................................................................................ 6
Komponente SOA Registra ...................................................................................................... 6
Workflow Engine ......................................................................................................................... 7
Servis Broker ............................................................................................................................... 7
SOA Supervizor ............................................................................................................................ 8
Bezbjednost SOA sistema ......................................................................................................... 10
Zakljuak.................................................................................................................................... 10
Bazne tehnologije prenosa podataka ........................................................................................... 11
XML ........................................................................................................................................... 11
XML sadraj ........................................................................................................................... 11
XML shema i validacija .......................................................................................................... 13
XML parsiranje ...................................................................................................................... 13
JSON .......................................................................................................................................... 14
JSON tekst ............................................................................................................................. 15
JSON vrijednosti .................................................................................................................... 15
JSON znakovni niz ................................................................................................................. 16
JSON objekti .......................................................................................................................... 16
JSON nizovi ............................................................................................................................ 16
JSON brojevi .......................................................................................................................... 16
Primjer JSON sadraja ........................................................................................................... 17
Zakljuak.................................................................................................................................... 17
Protokoli za razmjenu poruka putem weba ................................................................................. 18
SOAP (Simple Object Access Protocol) ..................................................................................... 18
2

RPC (Remote Procedure Call)................................................................................................ 19
Opis SOAP poruke ................................................................................................................. 19
SOAP specifikacija ................................................................................................................. 20
Princip procesiranja .............................................................................................................. 20
Metode prenosa podataka ................................................................................................... 21
Plain-text poruke ................................................................................................................... 21
Must Understand .................................................................................................................. 21
Nedostaci SOAP-a ..................................................................................................................... 21
Putanja poruke ...................................................................................................................... 22
Nepostojanje stanja .............................................................................................................. 22
Primjer SOAP poruke ............................................................................................................ 22
RESTful Web Servis ................................................................................................................... 23
Koritenje HTTP metoda ....................................................................................................... 23
Stateless protokol protokol bez stanja .............................................................................. 25
URI kao struktura direktorija ................................................................................................ 26
Koritenje XML i JSON za prenos podataka ......................................................................... 26
Praktini primjeri ........................................................................................................................... 27
Primjer SOAP ASMX web servisa: eGovernment ...................................................................... 27
Primjer RESTful web servisa u Java programskom jeziku: jParking .......................................... 30
Primjer konzumacije RESTful web servisa kroz Android ........................................................... 33
Primjer RESTful web servisa u Ruby on Rails: etf.ba v2 ............................................................ 35
Zakljuak........................................................................................................................................ 40

3

SOA (Service-oriented architecture)
Postoje razliite definicije Service-Oriented architecture (SOA), s tim da nijedna nije univerzalno
prihvaena. Ono to je za svaku od njih zajedniko jeste rije servis (usluga). Za SOA pristup,
servis ili usluga je samostalna, distribuirana komponenta koja se odlikuje visokim stepenom
modularnosti i koju se moe samostalno primjenjivati. Dostupna je na mrei i moe joj se
pristupiti preko imena ili lokacije na kojoj se nalazi. Postoje posebni direktoriji u kojima se
servisi registriraju tako da budu prepoznatljivi i da ih korisnici mogu pronai. Ove karakteristike
opisuju idealan servis. U praktinim primjenama, servisi u servisno-orijentiranim sistemima ne
posjeduju sve navedene karakteristike, npr. prepoznatljivost servisa.
SOA je arhitektura koja treba da unaprijedi poslovanje razlaganjem poslovnih procesa na vie
servisa koji meusobno sarauju da bi se izvrila neka aktivnost. Meutim da bi se SOA
razumjela u potpunosti neophodno je bolje upoznavanje sa njenim komponentama, emu
slue, kako funkcioniu i na koji nain su povezane. Komponente se razmatraju kao apstrakcije.
Komponente
Osnovne komponente SOA arhitekture su:
ESB(Enterprise Service Bus)
SOA Registar
Workflow Engine
Servis Broker
SOA Supervizor
Svaka od ovih komponenti ima odreenu, nezavisnu od drugih komponenti, ulogu u sistemu
kao i u saradnji sa ostalim dijelovima. ESB se brine o porukama koje se prenose izmeu
komponenti SOA sistema. SOA registar sadri informacije o lokacijama SOA komponenti.
Workflow engine je tehnologija koja povezuje ljude sa ljudima, ljude sa procesima i procese sa
procesima, dok servis broker povezuje servise sa servisima to na kraju omoguava rad
poslovnih procesa. Uloga SOA supervizora je da se pobrine da cijeli sistem funkcionie skladno i
predvidivo.



4


Slika 1. Komponente SOA arhitekture
ESB (Enterprise Service Bus)
ESB predstavlja centar za komunikaciju servisa u okviru SOA sistema. Dizajniran je da
funkcionie kao posrednik izmedu SOA komponenti, infrastrukturnih servisa i poslovnih
procesa. Povezuje se sa razliitim tipovima srednjeg sloja (middleware) sistema, skladitima
definicijama metapodataka, registrima i interfejsima aplikacija. Bitno je napomenuti da ESB nije
hardverska ve skup softverskih komponenti. Postoje razliite vrste ESB-a i razlikuju se po
svojim mogunostima. Svaki ESB ima apstraktni sloj koji je odgovoran za upravljanje porukama i
na taj nain omoguava spajanje i komunikaciju softverskih komponenti. Neki od njih mogu da
funkcioniu sa raznim vrstama poruka od e-maila do SOAP-a, neki implementiraju i enkripciju.
ESB moe funkcionisati i kao servis broker, moe posjedovati i svoj registar pa ak moe i
preuzeti neke funkcije SOA supervizora. Ovo je dobar pokazatelj da se ESB razvijao nezavisno od
SOA-e. Tako da je mogue imati ESB bez implementacije SOA sistema i obrnuto, naravno ovo je
mogue samo u manjim SOA sistemima.
Kada kompanija implmentira ESB obino poinje sa jednim ESB-om i on je sasvim dovoljan da
zadovolji trenutne potrebe kompanije. Kako raste SOA sistem tako je neophodno uvesti nove
ESB sisteme i povezati ih u federaciju. Federacija je skup ESB sistema koji pruaju uslugu na
nivou cijelog poslovanja. Svaki ESB posjeduje svoja pravila i polise ali ona potpadaju pod vii
skup SOA pravila. U sutini ESB prua mogunost povezivanja softverskih komponenti i servisa u
fleksibilnu vezu (loose coupling).
5

Pod ovim se podrazumijeva da ESB prua sloj koji omoguava komponentama da pozivaju i
koriste servise drugih komponenti na jednostavan nain. ESB prua mogunost koritenja ve
postojeih i starih aplikacija njihovim povezivanjem. Fleksibilna veza omoguava povezivanje
neogranienog broja korisnikih interfejsa, koji mogu pozivati aplikacije i servise koji se nalaze
na razliitim paltformama, u zajedniku mreu.
Servisi ESB-a
ESB izvrava infrastrukturne poslove koji bi inae morali da budu implementirani u samu
aplikaciju. Servisi koje nudi ESB su:
Messaging service (Servis poruka) podrava irok spektar poruka, prua inteligentno
rutiranje na osnovu konteksta i garantuje isporuku. Takoe moe kombinovati i dijeliti poruke.
Managment service (Upravljaki servis) prati performanse i reaguje u sluaju velike
latencije, implementira prioritete i globalna pravila aplikacijama i svim komponentama koje
povezuje.
Interface service (Interfejs servis) potvruje validnost poruka uporeivanjem sa XSD-om
(XML Schema Definition) koja se nalazi u ESB registru. Podrava standarde web servisa i pruaju
adaptere za interfejse koji nemaju podrku za web servise.
Mediation service (Posrednicki servis) mijenja format poruke radi usklaivanja sa
aplikacijom.
Metadata service (Servis meta podataka) - povezan sa posrednikim servisom, takoe
mijenja formate poruka koristei se definicijama metapodataka koje se nalaze u registru.
Security service (Sigurnosni servis) vri enkripciju podataka i ukljuuje standardizovani
sigurnosni metod autorizacije, autentifikacije i pregleda svih aktivnosti ESB-a.
6


Slika 2. Povezivanje dva programa preko ESB-a
SOA Registar
SOA Registar je centralna veza koja omoguava otkrivanje poslovnih servisa i prua opise svih
servisa koji imaju referencu u tom registru. Svaki servis koji je zabiljeen u registru je morao da
proe kroz verifikaciju od strane poslovnog i IT menadmenta. U registru je takoe zabiljeena
historija svakog servisa, ko je kreator servisa, ko ima mogunost promijene servisa, kako se
koristi i ko ima pravo pristupa. SOA Registar nije pasivni direktorij ve se mijenja u stvarnom
vremenu (real-time registry), mijenja se u skladu sa promjenama poslovnih pravila. Posjeduje tri
kljune funkcije:
Objavljivanje i pruanje mogunosti otkrivanja servisa
Sakupljanje i upravljanje metapodacima poslovnih servisa
Upravljanje koritenjem poslovnih servisa

Komponente SOA Registra
Sve to je smjeteno u registru je u formi metapodataka i tie se pravila upravljanja servisima u
okviru SOA okruenja. SOA Registar se sastoji od:
Komponente za opisivanje interfejsa Web servisa Koristi se UDDI (Universal
Description, Discovery and Integration) standard koji podravaju svi SOA Registri. Kreiran
je pomou XML tehnologije.
Komponente za opisivanje ostalih tipova iterfejsa Pored interfejsa kreiranih XML-om
mogue je koristiti ve postojee interfejse. Dovoljno je imati podatke o pravilima
korienja postojeih interfejsa.
7

Definicije poslovnih procesa Za izvrenje nekog poslovnog procesa neophodno je
povezati vie komponenti. Da bi se one povezale na pravi nain i da bi se izvrio poslovni
proces neophodno je da imamo mapu i potpunu definiciju poslovnih procesa. Definira se
npr. ulaze i izlaze.
Pravila poslovnih procesa Svaki proces mora se izvravati u okviru odreenih pravila.
Pravila su centralizovana i smjetena u SOA registar. Ovo takoe olakava pronalaenje
pravila koja se tiu odreenog poslovnog procesa.
Opisa nivoa performansi i dostupnosti servisa Skup pravila koja opisuju nivo
preformansi i dostupnosti koje raunarska mrea mora obezbijediti za rad odreenog
servisa.
Pravila upravljanja Sadraj registra mora se povinovati odreenim pravilima
upravljanja. Svaka promjena se mora kontrolisati da ne bi dolo do greaka koje se mogu
odraziti na funkcionalnost cijelog sistema.
Workflow Engine
Worklow Engine predstavlja softversku komponentu koja povezuje cijeli poslovni proces (radni
tok ili tok rada) u jednu cjelinu, prenosei rad sa jedne individue ili procesa ka drugoj dok se
cijeli proces ne izvri. Tehnologije za razvoj Workflow-a omoguavaju modeliranje poslovnih
procesa da bi se dobio workflow pattern. Workflow razvoj je nastao daleko prije SOA-e i postoje
mnogi proizvodi ovog tipa, esto sa akcentom na specifinu oblast kojoj su namijenjeni. Neki od
njih su:
jBPM Ovo je workflow engine kompanije jBoss koji izvrava procese opisane u BPEL-u
(Business Process Execution Language) ili u sopstvenom jeziku za definisanje procesa
jPDL-u.
OSWorkflow Ovo je proizvod open source projekta OpenSymphony. Nastoji da prui
fleksibilnost u razvoju i ne posjeduje sopstveni grafiki interfejs.
Apache ODE (Orchestration Director Engine) Proizvod softverske open source
fondacije Apache. Izvrava poslovne procese napisane u skladu sa standardom WS-
BPL(Web Services Business Process Execution Language).
W4 BPM Embedded Edition Proizvod Evropske softverske kompanije W4 koji podrava
veliki broj operativnih sistema(Linux, Solaris, Windows, HPUX, Aix, iSeries - AS400 i
zSeries) i baza podataka (MySql, PostgreSQL, Oracle, SQLServer, DB2 i Informix).
Servis Broker
Servis broker je komponenta koja omoguava funkcionalnost veza izmedu svih ostalih
komponenti.
8

Spaja vie komponenti u niz koje ine poslovni proces. Koristi informacije o komponentama koje
nalazi u SOA registru i spaja ih pripremajui ih za rad workflow engine-a. Servis broker zapoinje
sve procese i kada zavri sa spajanjem komponenti u poslovnom procesu prelazi na sljedei
zadatak spajanja. Servis broker je neophodna komponenta zato to je SOA sistem napravljen od
slabo povezanih (loosely coupled) komponenti koje se moraju povezati u smislenu cjelinu da bi
se izvrio neki poslovni proces. On orkestrira rad komponenti pravei vezu izmedu njih pomou
informacija iz SOA registra.
Na slici 3 ilustrativno je prikazano kako broker funkcionie u saradnji sa registrom. Slika
prikazuje povezivanje servisa narudbe sa servisom provjere kreditne sposobnosti. Servis
narudbe, preko brokera koji koristi informacije iz registra o servisu provjere kreditne
sposobnosti, vri zahtjev za usluge servisa provjere kreditne sposobnosti. Servis broker koristi
informacije iz registra kako da pronade ova dva servisa ali i po kojim pravilima rade i kako da
objedini dva skupa pravila u jednu funkcionalnu cjelinu. Na slici je prikazan policy engine koji
implementira pravila rada i koji je zapravo dio registra. Informacija o servisu provjere kreditne
sposobnosti je objavljena u registru, to se takoe vidi na slici.


Slika 3. Rad servis brokera u saradnji sa SOA registrom
SOA Supervizor
Sistem slabo povezanih komponenti (loose coupling) ne moe biti toliko efikasan i pruiti nivo
performansi kao sistem vrsto povezanih komponenti (tight coupling). Zato je uloga SOA
supervizora toliko bitna, on omoguava prihvatljiv nivo usluga i performansi servisa. Takoe je
bitno napomenuti da SOA supervizor mora biti aktivan dok god je neki servis aktivan i vri se
neki poslovni proces. Kako kompanija sve vie implementira SOA sistem tako ce se poveavati i
zahtjevi koje SOA supervizor mora da ispuni da bi se odrao prihvatljiv nivo performansi. Slika 4
prikazuje rad supervizora u saradnji sa ostalim komponentama, ovakav sistem se ne moe jo
uvijek nai u praktinoj primjeni ali je to ono emu se tei.
9


Slika 4. Rad SOA supervizora u SOA okruenju
Cijeli proces zapoinje servis broker slanjem poruke SOA supervizoru da je spojio odreene
servise i tako omoguio poetak nekog poslovnog procesa. SOA supervizor se konsultuje sa
registrom oko detalja vezanih za poslovni proces da bi mogao da postavi softver za nadgledanje
svih neophodnih komponenti. Ovo nadgledanje izvrava SLA (Service Level Agreement)
monitoring komponenta koja preko lokalnih adaptera aplikacija dobija izvjetaje o nivou
performansi. Izvjetaji se proslijeuju SOA supervizoru koji ih prikazuje na konzoli da bi se mogli
pratiti u realnom vremenu. Kada se pojavi problem SOA supervizor obavjetava infrastrukturne
servise, koji bi trebali da rijee problem. Ako ovi servisi nisu u mogunosti da rijee problem
obavjetava se osoblje o problemu koji se pojavio. Stvari u realnosti izgledaju dosta drugaije
nego to su prikazane na dijagramu. Veina kompanija nije za sada u mogunosti da obezbjedi
rad SOA supervizora kako je prikazano na slici. Ovo ne znai da one nemaju funkcionalan SOA
sistem, ve da im za sada to nije neophodno zato to nisu implementirali SOA-u u potpunosti.
Ali vremenom e se SOA sistem iriti i da bi se postigla ovakva funkcionalnost SOA supervizora
prije svega je potrebno obezbijediti:
Dobro definisane nivoe prihvatljivih performansi SLA (Service Level Agreement)
Potpuno funkcionalan infrastrukturni softver
Mape poslovnih procesa
Popis hardverske opreme i softvera koji se koristi

10

Bezbjednost SOA sistema
Bitna stavka svakog informacionog sistema je bezbjednost, pogotovo kada se radi o otvorenom
informacionom sistemu koji ima veliki broj korisnika i koji prua veliki broj usluga. Ovo pravilo
takoe vai i za SOA sisteme. Nijedna tehnologija ne nudi savreno rjeenje i da bi se postigao
zadovoljavajui nivo bezbjednosti, neophodno je razumjeti osnovne principe sigurnosti
informacija i razumjeti dizajn i arhitekturu SOA sistema. Kljuno za dobar sistem bezbjednosti je
da se sigurnosna strategija i plan razvoja usvoje u ranim fazama implementacije SOA sistema.
Dobri sigurnosni sistemi omoguavaju poslovnim aplikacijama da ispune sva oekivanja
organizacije uz implementaciju osnovnih bezbjednosnih aspekata, kao to su:
Autentifikacija
Autorizacija
Federativni identitet
Privatnost
Integritet
Nemogunost poricanja (non-repudiation)
Preglednost
Dostupnost
Zakljuak
SOA arhitekture razvile su se s ciljem ostvarivanja suradnje izmeu razliitih sistema kako bi se
ostvarile odreene poslovne funkcije. Istovremeno SOA akcenat stavlja na ponovnu
upotrebljivost napisanog softvera (servisa) - jednom napisani servis (primjerice, web servis
hidrometeorolokog zavoda koji omoguava pristup dugoronoj vremenskoj prognozi za
podruje Bosne i Hercegovine) moe se koristiti u bilo kojem kontekstu: portali mogu
preuzimati podatke i prikazivati ih kao svoj sadraj, organizacije mogu automatski sa istog
servisa preuzimati sadraj i davati ga kao ulaz u svoje sisteme (npr. za planiranje iznosa poticaja
poljoprivredi) itd. Kljuno je za napomenuti da se servisi nalaze na nekoj lokaciji, da imaju svoju
definiciju i odreene ulaze i izlaze, te da reaguju na poruke koje im se poalju. Kao takvi, mogu
initi sastavne dijelove irih sistema zasnovanih na ranije izloenim principima ili design
patternima SOA-e.
11

Bazne tehnologije prenosa podataka
Kao to je izloeno u opisu SOA-e, servisi i korisnici meusobno surauju tako to razmjenjuju
poruke. U kontekstu web servisa razmjena poruka ide na sljedei nain: poruka se sprema u
nekom od formata za razmjenu, poruka se stavlja kao tijelo HTTP(S) zahtijeva i kao takva se
prenosi internetom do odredita. Pri tome se pod odreditem ne podrazumijeva samo domena
ve i lokalna putanja na domenu (puna putanja). Odredite preuzima poruku iz zahtijeva i
obrauje ju ovisno o tome koja je metoda kojeg servisa na kojem domenu zahtijevana. Nakon
to obrada zavri (bilo uspjeno, bilo neuspjeno), sastavlja se odgovor i takoer se sprema u
nekom od formata za razmjenu te se stavlja kao tijelo HTTP odgovora. HTTP odgovor se alje
originalnom poiljatelju. ema je gotovo u potpunosti ista kao i ema obinog zahtijeva za
nekim web sadrajem.
Formati za razmjenu moraju biti prenosivi putem interneta to znai da binarni podaci otpadaju.
Koriste se tekstualni formati, a najkoriteniji su XML (stariji i prenosi veu koliinu
metapodataka) i JSON (mlai i prenosi manju koliinu metapodataka). JSON je i slobodnije
strukturiran pa predstavlja podesan izbor za upotrebu uz RESTful web servise o kojima e biti
rijei kasnije.
XML
Extensible Markup Language (XML) je otvoreni opisni jezik koji slui za razmjenu struktuiranih
dokumenata putem Interneta. Dizajniran je kao tekstualni format podataka i koristi Unicode
kodiranje zbog podrke za sve svjetske jezike i charsetove. Za razliku od HTML, XML omoguava
definiciju, prenos, validaciju i itanja podataka pri koritenju razliitih platformi i aplikacija. Iako
je namjenjen za definisanje struktura dokumenata, koristiti se za prezentaciju struktura
podataka koje se koriste sa web servisima. XML definie skup pravila kojima se opisuje struktura
dokumenta u formatu koji je pogodan za ljudsko razumjevanje, ali isto tako i za mainsko
prepoznavanje.
XML je proiriv jezik, to znai da je mogue proiriti jezik kreirajui nove oznake (tag) koje e
opisivati nove podatke po potrebi, sve dok nove oznake potivaju postojeu XML sintaksu koja
je specificirana od strane W3C (The World Wide Web Consortium). Za mnoge programske
jezike postoji podrka za procesiranje XML podataka. XML se javlja u mnogim dokument
formatima (MS Office, Open Office XML), a koristiti se i u komunikacionim protokolima kao to
je XMPP.
XML sadraj
Svaki XML dokument bi trebao poeti sa deklaracijom koja nudi informacije o sadraju untar
dokumenta, kao to su verzija XML specifikacije koja se koristi i nain enkodiranja znakova u
dokumentu.
12

<?xml version="1.0" encoding="UTF-8"?>
Sadraj koji se javlja unutar jednog XML dokumenta moe se podijeliti na dva tipa, opisni i
podatkovni. XML parser je zaduen za prepoznavanje i procesiranje strukture koristei
jednostavan skup pravila. Ukoliko znakovni niz poinje znakom ' < ', a zavrava znakom ' > ',
odnosno ako poinje znakom ' &' i zavrava znakom ' ; ' tada taj niz znakova predstavlja opisni
sadraj. Sav ostali sadraj unutar dokumenta predstavlja podatkovni sadraj. Postoji par
izolovanih sluajeva gdje se podatkovni sadraj javlja izmeu znakova '<' i '>', ali to je skup
konano prebrojivih izuzetaka.
Oznake (tag) predstavljaju opisni sadraj i koriste se za definisanje elemenata. Poinju znakom
'<', a zavravaju znakom '>. Razlikujemo sljedee vrste tagova:
Poetni tag <html>
Krajnji tag </html>
Samostalni tag <br/>
Elementom se naziva struktura untar dokumenta koja sadri poetni tag i pripadajui krajnji tag
ili se sastoji iz samostalnog tag-a. U prvom sluaju sav sadraj koji se nalazi unutar oznaka se
naziva podatkovnim sadrajem elementa. Element moe sadravati i opisni dio, kao i druge
elemente, koji se nazivaju dijete elementom, ime se kreira hijerarhija. Atributima se nazivaju
vrijednosti koje dodatno opisuju pojedini elemenet. To su parovi naziva i vrijednosti koji se
nalaze unutar poetnog tag-a ili samostalnog tag-a. Naziv je obavezan kako bi se atribut mogao
referencirati, a vrijednost moe biti neka od standardnih tipova podataka. Ukoliko je potrebno
da pod jednim nazivom atribut nosi dvije ili vie vrijednosti potrebno je koristiti formatiranje
koje XML ne definie. Obino se vrijednosti rastavljaju zarezom, dvotakom ili razmakom. HTML
primjer:
<div name="div2" class="plavo pocetna" >Pozdrav!</div>
Sav sadraj XML dokumenta koristi Unicode kodiranje, to obuhvata UTF-8 i UTF-16, osim par
izuzetaka koji predstavljaju kontrolne znakove. Podran je prikaz svih znakova koji se mogu
prikazati Unicode kodiranjem, to podrazumijeva sva postojea pisma, te za znakove koje nije
mogue direktno napisati postoji kombinacija simbola koja omoguava njihovo koritenje. Iako
je mogue koristiti ASCII kodiranje, koje predstavlja podskup Unicode kodiranja, nije
garantovano da e XML parser prepoznati kodiranje.
13

Komentare u XML dokumentu mogue je postaviti bilo gdje van opisnog sadraja i ne bi se
trebali postavljati prije XML deklaracije. Poetak komentara se oznaava sa "<!--", a zavretak
znakovima "-->", pri emu nije dozovljeno koristiti "--" unutar komentara. Kao sadraj
komentara ne mogu se javljati znakovi van opsega znakovnog kodiranja budui da nije mogue
eksplicitno prikazati neki znak.
XML shema i validacija
Po postojeoj XML specifikaciji definisan je skup sintaksnih pravila koje namee specifikacija
kojima se karakterie dobro formiran XML dokument. Neka od pravila su sljedea:
Sadraj dokumenta ine validni Unicode znakovi
Znakovi '< i & se javljaju samo u opisnom dijelu sadraja
Oznake otvaranja, zatvaranja i samostalne oznake koje oznaavaju elemente su pravilno
ugnjedene, uparene i ne preklapaju se
Oznake elemenata case-sensitive i poetni i krajnji tag se moraju podudarati.
Postoji jedan korijenski (root) element koji sadri sve ostale elemente
U sluaju da XML parser pri itanju sadraja XML dokumenta pronae krenje pomenutih
pravila ili nepravilnu strukturu dokumenta zaustavlja se procesiranje i prijavljuje greka. Za
razliku od drugih opisnih jezika kao to je HTML koji dozvoljava da itav dokument bude
procesiran iako kri pravila.
Po XML specifikacji validan XML dokumet je dobro formiran i prati pravilla definisana po
Document Type Definition(DTD). To znai da su svi elementi i atributi deklarisani po DTD i da
slijede gramatika pravila koja specificira DTD. DTD predstavlja primjer sheme odnosno
gramatike koja ograniava skup elemenata koji se mogu korisititi pri kreiranju dokumenta, koji
atributi im se mogu pripisati i da li je dozvoljeno gnijzditi elemente. DTD je mogue sadrati u
istom dokumentu u kojem se nalazi i XML sadraj.
XML parsiranje
XML specifikacija ne definira nain procesiranja podataka sadranih unutar XML dokumenta. Iz
tog razloga pojavilo se mnogo API-a kojima se pristupa XML strukturi i sadraju, neki su postali
industrijski standardi i dijele se na sljedee kategorije:
Stream orijenstisani (SAX, StAX)
Struktura stabla (DOM)
XML data binding
Transformacijski jezici (XSLT, XQuery)

14

Stream orijentisani pristup dokumentu zahtijeva manje memorijskih resursa i za odreene
zadatke koji podrazumijevaju prolaz kroz sve elemente u dokumentu predstavljaju najbolji
izbor, budui da je ovo najjednostavniji pristup. Nedostatak ovakvog pristupa je spor pristup
nasuminom elementu unutar strukture.
Pretraivanje stabla i data binding (vezivanje podaka) predstavljaju pristupe koji zahtijevaju
mnogo vie memorije, ali su lako iskoristivi od strane programera. DOM predstavlja API koji
omoguuje navigaciju kroz cijeli dokumente kao kretanje kroz stablo, gdje sadraj dokumenta
predstavlja vorove stabla. DOM dokument moe biti generisan od strane parsera ili runo
definisan od strane korisnika. Nedostatak velikih zahtjeva za memorijom je posljedica potrebe
da se cio dokument uita u memoriju prije nego li se dopusti pristup bilo kojem objektu. Data
binding pristup sve XML podatke predstavlja kao hijerarhiju tipizovanih klasa, za razliku od
apstraktnih objekata sa kojim radi DOM parser. Pojednostavljuje programiranje i probleme je
mogue uoiti tokom programiranja. XML serijalizacija koristi data binding.
Primjer XML datoteke
<menu id="file" value="File">
<popup>
<menuitem value="New" onclick="CreateNewDoc()" />
<menuitem value="Open" onclick="OpenDoc()" />
<menuitem value="Close" onclick="CloseDoc()" />
</popup>
</menu>
JSON
Skraenica JSON stoji za JavaScript Object Notation i predstavlja otvoreni tekstualni format koji
za razmjenu koristi stuktuirane podatke pri koritenju razliitih programskih jezika. Najvea
primjena se ogleda u komunikaciji tj. prenosu podataka izmeu servera i web aplikacije.
Sintaksa koju koristi JSON reprezentacija podataka je jednostavna i primjenjiva u razliitim
kontekstima. JSON definie mali skup pravila po kojima se vri strukturiranje podataka unutar
dokumenta, takoer je definisan i skup znakova koji se koriste pri definiranju strukture
podataka kao to su su zagrade (oble, uglaste), dvotaka, zarezi, te drugi znakovi. JSON se razvio
iz naina reprezentacije objekata u JavaScript odnosno iz ECMAScript.
Pri radu sa razliitim programskim jezicima javlja se razlika u njihovoj prodrci pri radu sa
objektima i ogranienjima koja se pri tome nameu. Kako bi se omoguio prenos podataka
neovisan od programskog jezika JSON pri komunikaciji ne upotrebljava konvencionalni model
objekta ve prua jednostavan nain prikazivanja kolekcije podatkovnih parova koji se sastoje
od naziva i vrijednosti. Ovakav nain prikaza podataka je umnogome ve prisutan u mnogim
programskim jezicima, uobiajeni nazivi ovakvih i slinih struktura su: record, struct, dict, map,
hash ili object.
15

Sadaj ovakvog prikaza podataka predstavlja tekst koji se sastoji od niza znakova Unicode
kodiranja. Pri radu sa numerikim vrijednostima ponovo se javlja razlika u razliitim tipovi raznih
programskih jezika, naina prikazivanja brojeva sa pominim zarezom te veliinom varijabli.
Kako bi se omoguila razmjena podataka JSON nudi jedinstven nain predstavljanja brojeva kao
niza cifara, to je dovoljno za razmjenu, a interna reprezentacija brojeva zavisi od programskog
jezika.
JSON takoer podrava prikaz numerisanih listi vrijednosti, odnosno prikaz niza elemenata.
Takve strukture su ve poznate u programiranju kao array, vector, list. Budui da je pri
koritenju ovih struktrura mogue njihovo ugnjedavanje, to omoguava prikaz sloenijih
struktura kao to su stabla, ali ne i ciklinih grafova. Omoguava se jedinstven nain prenosa, a
interpretacija se ostavlja kao zadatak programskom jeziku.
JSON tekst
JSON sadraj predstavlja niz tekstualnih simbola Unicode kodiranja. Skup simbola ukljuuje est
simbola kojima se definie struktura podataka, podatkovne znakovne nizove, brojeve, tri
predefinisane znakovne konstante.
Znakovne konstante su: true, false, null. Znakovi koji definiu strukturu su:
[ - U+005B
{ - U+007B] - U+005D
} - U+007D
: - U+003A
, - U+002C
Pojava znakova praznog prostora je dozvoljena prije i poslije svakog znakovnog simbola. Pod
znakovima praznog prostora podrazumijevaju se razmak, uvlaenje i novi red. Nije dozvoljena
pojava ovih znakova u simblima, razmak je dozvoljen u vrijednostima tipa znakovnog niza.
JSON vrijednosti
Vrijednosti koje se pojavljuju u parovima mogu biti:
String - znakovni niz
Number - numerika vrijednost
Array - niz elemenata
Object - objekat
True - logika konstanta
False - logika konstanta
Null - nedodjeljena vrijednost
16

JSON znakovni niz
Znakovni niz u JSON predstavlja svaku kolekciju znakova okruenih dvostrukim navodnicima. Pri
umetanju znakova u niz potrebno je paziti da je za prikaz odreenih znakova potrebno koristiti
posebne kombinacije kao pri koritenju znakovnih nizova u mnogim programskim jezicima. Ti
znakovi su: \, \\, \/, \b, \f, \n, \r, \t.
Svaki znak u nizu je mogue predstaviti koristei heksadecimalni zapis. Takav zapis se sastoji od
est znakova, prvi je kosa crta '\, zatim oznaka Unicode kodiranja u, te zatim slijedi
heksadecimalni kod za specifian znak.
JSON objekti
Objekat je struktura koja se predstavlja kao par vitiastih zagrada koji sadri nijedan ili vie
parova naziva i vrijednosti. Svaki naziv je tipa string (znakovni niz). Nakon naziva sljedi dvotaka
(:) kojom se razdvaja naziv od vrijednosti. Nakon vrijednosti slijedi zarez kojim se razdvajaju
razliiti parovi untar objekta.

Slika 5. Struktura JSON objekta
JSON nizovi
Nizovi predstavljaju kao struktura koju ini par uglastih zagrada unutar kojih se nalaze
vrijednosti. Vrijednosti unutar niza su odvojene zarezon, a poredak elemenata u nizu je bitan.

Slika 6. Struktura JSON nizova
JSON brojevi
Brojevi su predstavljeni u decimalnom sistemu bez vodeih nula. Dozovljeno je koritenje
vodeeg minusa za predstavljanje negativnih brojeva. Takoer je dozvoljeno koritenje
decimalnog zareza. Mogue je koristiti eksponencijalni zapis sa bazom 10 koristei e ili E, sa
predznakom prije eksponenta.
Glavni nedostatak pri radu sa brojevima je taj to ih je mogue predstaviti kao numerike
vrijednosti, ali i kao znakovni niz. Ukoliko vrijednost treba da sadri vodeu nulu prilikom
konverzije podataka moe doi do gubljenja informacija.
17

Da ne bi dolo do prije navedenih problema pri koritenju razliitih naina prezentacie brojeva
uvodi se shema koja definie karakteristike podataka kako bi se mogla vriti validacija.


Slika 7. Struktura JSON broja
Primjer JSON sadraja
{"menu": {
"id": "file",
"value": "File",
"popup": {
"menuitem": [
{"value": "New", "onclick": "CreateNewDoc()"},
{"value": "Open", "onclick": "OpenDoc()"},
{"value": "Close", "onclick": "CloseDoc()"}
]
}
}}
Zakljuak
U ovom poglavlju ukratko su opisana dva najkoritenija formata za razmjenu podataka putem
weba. Formati se odlikuju vlastitim skupom pravila kako predstaviti objekte i njihove atribute i
vrijednosti, dok je na stranama koje komuniciraju da se usuglase oko zajednike predstave
objekata, kao i da se programski serijalizacija i deserijalizacija (pretvaranje objekta u XML/JSON
zapis i kreiranje objekta iz XML/JSON zapisa) obave na tehniki korektan nain. U suprotnom
nisu ispunjeni elementarni zahtijevi za nuenje i konzumaciju web servisa.
18

Protokoli za razmjenu poruka putem weba
U prethodnom poglavlju objanjeno je kako se vri razmjena podataka, no podaci putuju
mreom zapakovani u odgovaraue poruke.
U okviru ovog seminarskog rada biti e izloena dva nakoritenija protokola: SOAP kao
standardizovani, stariji, i sloeniji protokol, te REST kao jednostavniji i noviji nestandardizovani
nain razmjene poruka. Slino kao kod kombinacije XML/JSON, SOAP je sporiji (i bazira se na
XML u kojem je sve potrebno detaljno definirati), dok je REST bri i zahtijeva manje resursa (i
prikladan je za ROA tj. arhitekture zasnovane na resursima gdje se svrha servisa poistovjeuje sa
upravljanjem i radom sa resursima - sve ime servis raspolae jesu resursi).
SOAP (Simple Object Access Protocol)
SOAP je dizajniran tako da predstavlja protokol za decentralizovano i distribuirano okruenje,
koje iskoritava postojeu Internet infrastrukturu i XML kako bi se omoguila razmjena
podataka izmeu vorova na mrei.
SOAP predstavlja nain komunikacije izmeu vorova mree kod kojeg se ne pamte stanja i
osigurava je jednostrana razmjena poruka. Uensnici u komunikaciji se nazivaju SOAP poiljatelj
i SOAP primatelj. Na osnovu postojeeg naina razmjene poruke i prenosnog mrenog sloja
kombiniranjem poruka mogue je kreirati kompleksniju komunikaciju koja ukljuuje zahtjeve i
odgovore. Ovaj protokol je jednostavan i nezavisan od platforme, naina prenosa podataka i
operativnog sistem na kojemu se koristi, jer se oslanja na koritenje vremenskih sistema
koristei HTTP ili SMTP protokol i XML opisni jezik. SOAP je preporuka W3C.
SOAP moe kreirati osnovni sloj na kojem se moe izgraditi stek protokol web servisa pruajui
osnovnu podrku za razmjenjivanje poruka na osnovu kojeg se moe graditi struktura web
servisa. Protokol je baziran na XML-u i sastoji se od tri dijela. Dio koji definira ta je sadraj
poruke i kako se ona procesira naziva se koverta (envelope). Drugi dio je skup pravila po kojima
se vri kodiranje podatkovnih tipova, te dio koji definie konvenciju po kojoj se prikazuju pozivi
procedura i odgovori. SOAP karakteriu tri najvee znaajke, a to su: proirivost, neutralnost i
nezavisnost. Neutralnost se ogleda u tome da se SOAP moe koristiti preko bilo kojeg
transportnog protokola kao to su: HTTP, SMTP, TCP ili JMS), nezavisnost u tome da se SOAP
moe koristiti u raznim programskim jezicima. SOAP arhitektura se sastoji od nekoliko nivoa
specifikacija za: format poruke, patterne razmjene poruka, modele procesiranja poruka i
proirivanje protokola.
SOAP je nasljednik XML-RPC, s tim da odreene karakteristike nije naslijedio direktno kao to je
neutralnost prenosa. Postoje dva tipa SOAP zahtjeva. Prvi je RPC (Remote Procedure Call)
zahtjev koji je slian drugim zahtjevima u distribuiranim arhitekturama.
19

Procedura poziva je sinhronizovana, klijent poalje poruku i eka da dobije odgovor ili poruku o
greci od strane servera. Drugi tip SOAP zahtjeva jeste document zahtjev, pri kojem se itav XML
dokument prosljeuje izmeu klijenta i servera unutar SOAP poruke.
RPC (Remote Procedure Call)
SOAP-RPC predstavlja implementaciju RPC-a. U ovom sluaju funkcija na udaljenoj maini se
poziva kao da je lokalna funkcija. Sva razmjena podataka preputena je SOAP-u i podaci se
spremaju u XML dokument. Klijent poziva web servis saljui parametre, a zatim prima povratnu
vrijednost. Web servisi RPC tipa prate zahtjev/odgovor komunikaciju pa su uglavnom
implementirani kao sinhroni protokoli. RPC poruka koristi HTTP-POST metodu i svi podaci se
razmjenjuju koristei XML.
Opis SOAP poruke
SOAP poruka predstavlja XML dokument koji je standardiziran. Na slici 8. dat je osnovni izgled
SOAP poruke. Korijenski element predstavlja tag (oznaka) koverte, koji sadri dva elementa:
body i header.
U body elementu su sadrani podaci koji omoguavaju razmjenu obaveznih informacija koje su
namjenjene konanom primatelju poruke. Poruka je sadrana u XML formatu. Ukoliko je RPC
zahtjev onda sadri struktuiranu povratnu vrijednost, argumente, odnosno izvjetaj o greci.
Drugi element header sadri nijedan ili vie tagova i otvoren je za izmjene kako bi se omoguila
fleksibilnost za budue primjene. Kako poruka putuje od servera do servera, tagovi unutar
header zaglavlja se itaju i ukoliko je potrebno vre se odreene akcije. Oznake koje se mogu
nai mogu predstavljati transakcijski ili sesijski ID da bi se definisalo stanje, mada mogu biti i
razne druge vrijednosti.

Slika 8. Struktura SOAP poruka
20

SOAP poruka je tipini XML dokument koji se sastoji od sljedeih elemenata:
Element Opis Obavezna
Envelope Identificira XML dokument kao SOAP poruku Da
Header Sadri informacije zaglavlja Ne
Body Sadri informacije o pozivu i odgovoru Da
Fault Informacije o greci koja se javila pri prenosu
poruke
Ne
SOAP specifikacija
Specifikacija SOAP definira okruenje za razmjenu poruka koje se sastoji od:
SOAP modela procesiranja
SOAP modela proirivanja
SOAP vezivanje za protokol podloge
SOAP definicije poruke
Model procesiranja definira skup pravila za procesiranje SOAP poruka. Model proirivanja
definie koncepte SOAP karakteristika i modula. Vezivanje za protokol podloge opisuje pravila
po kojima se iskoritava protokol podloge na koju se nadovezuje SOAP kako bi se omoguila
razmjena poruka izmeu SOAP vorova u strukturi.
Princip procesiranja
SOAP model procesiranja opisuje distribuirani model procesiranja, njegove uesnike, SOAP
vorove, te kako SOAP primatelj procesira SOAP poruku. Definiu se sljedei SOAP vorovi koji
uestvuju u komunikaciji:
SOAP poiljatelj - SOAP vor koji alje poruku
SOAP primatelj - SOAP vor koji prima i ita poruku
SOAP putanja poruke - niz SOAP vorova kroz koje putuje jedna SOAP poruka
SOAP izvorni poiljatelj - poiljatelj SOAP poruke koji ju je kreirano, prvi vor u putanji
SOAP poruke
SOAP posrednici - SOAP posrednik predstavlja SOAP poiljaoca i primaoca. Procesira
samo podatke sadrane u header bloku SOAP poruke i sprovodi akcije kako bi usmjerio
poruku ka konanom odreditu poruke
Konani primatelj SOAP poruke- konano odredite SOAP poruke. U ovom voru se vri
procesiranje sadraja header i body bloka SOAP poruke. Pri pojavi greaka u
komunikaciji izmeu vorova poruka ne mora stii na konano odredite. Konani SOAP
primatelj poruke ne moe obavljati ulogu SOAP posrednika za istu poruku.

21

Metode prenosa podataka
Za razmjenu SOAP poruka koriste se SMTP i HTTP protokoli aplikacijskog nivoa, ali je HTTP vie
koriten jer dobro funkcionie zbog Internet infrastrukture. SOAP takoer moe koristiti HTTPS
protokol koji koristi kodirani transportni protokol sa jednostrukom ili dvostrukom
autentifikacijom, to je preporuena metoda osiguravanja sigurnosti pri koritenju web servisa.
Glavna prednost koritenja SOAP jeste u mrenim protokolima koje koristi u odnosu na ostale
protokole kao to su GIOP/IIOP ili DCOM koje firewall esto filtrira.
Plain-text poruke
SOAP poruke koje se koriste u komunikaciji se alju kao obian tekst sa naglaenim zaglavljem,
za SOAP verziju 1.1 zaglavlje je:
Content-Type: text/xml
SOAPAction: http://example.com

U SOAP verziji 1.2 zaglavlje je promijenjeno:
Content-Type:application/soap+_xml;action=http://example.com
Sa ovom promijenom zaglavlja omogueno je da mrenim firewall pregleda poruku kako bi
provjerio njihovu sigurnost i validnost. Transparentnost pri slanju poruka je jedna od prednosti
nad ostalim distribuiranim protokolima. Ukoliko je firewall ostavio otvoren samo HTTP port za
mrenu komunikaciju to i dalje omoguava SOAP-u da ostvari prenos poruke.
Must Understand
Globalni atribut mustUnderstand se koristi kako bi se naglasilo da li je potrebno da primaoc
poruke procesira sadraj zaglavlja poruke. Ovaj atribut osigurava da se poruka nee proslijediti
ka sljedeem voru ukoliko prethodni vor nije ispravno interpretirao. Ukoliko vor dobije
SOAP poruku sa aktiviranim mustUnderstand atributom koju vor nije u stanju prepoznati,
poruka se ne prosljeuje i klijentu se vraa poruka greke.
Nedostaci SOAP-a
Pri radu sa podacima SOAP mora da definie neke osnovne tipove sa kojima radi kao to su
string, integer, date i ostali. Budui da na razliitim platformama reprezentacija i pohranjivanje
razliitih tipova podataka se razlikuje SOAP dozvoljava da se definiu novi tipovi podataka kroz
XML shemu. Ovo moe predstavljati problem jer moe uzrokovati kreiranje overhead-a,
zbunjujue je i predstavlja potencijalni problem prilikom implementacije. Jo jedan potencijalni
problem koji uzrokuje kreiranje novih tipova jeste veliina paketa koji se alje preko mree. Taj
problem je djelimino uzrok koritenja obinog (plain) teksta. Drugi protokoli alju mnogo
manje pakete.
22

Putanja poruke
Sa trenutnom verzijom SOAP-a nije mogue specificirati putanju poruke. Kao i sa svim ostalim
porukama koje se alju preko Interneta, paketi uzimaju razliite rute da bi stigli do odredita.
Poznavanjem putanje bi umnogome poboljalo pouzdanost protokola, takoer bi eventualno
omoguilo i detekciju izvora greke.
Nepostojanje stanja
SOAP poruke predstavljaju jednosmjernu transmisiju podataka od poiljaoca ka primaocu.
Ukoliko se pri prenosu koristi HTTP protokol koji je i sam po prirodi protokol koji ne biljei stanja
tada je potrebno ubaciti dodatne oznake u SOAP protokol koji bi tada omoguio uvanje stanja.
Po W3C specifikaciji ostavljen je otvoren header blok, odnosno zaglavlje kako bi se mogle
ubaciti dodatne oznake (tags) koje e sadravati neke identifikatore koji e oznaavati stanje.
Ipak nepostojanje stanja kod SOAP protokola predstavlja njegovu prednost u vidu brzine i
jednostavne implementacije, te su rijetki razlozi kada je zaista potrebno uvati stanje.
Primjer SOAP poruke
POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 299
SOAPAction: "http://www.w3.org/2003/05/soap-envelope"
<!- ->
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Header>
</soap:Header>
<soap:Body>
<m:GetStockPrice xmlns:m="http://www.example.org/stock">
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
23

RESTful Web Servis
Representation State Transfer (REST) predstavlja jednostavniju alternativu od SOAP-a. REST
definira komplet arhitekturalnih principa prema kojima je mogue dizajnirati Web Servise koji
se fokusiraju na sistemske resurse, ukljuujui adresiranje resursa te prenos resursa preko HTTP
protokola po irokom rasponu klijenata napisana u razliitim jezicima.
Implementacija REST WebServisa prati etiri osnovna principa dizajna:
Koritenje HTTP metoda
Stateless protokol protokol bez stanja
URI kao struktura direktorija
Koritenje XML i JSON za prenos podataka
U sljedeim poglavljima bit e dati tehniki razlozi zato su ova etiri principa vana za dizajn
REST Web Servisa.
Koritenje HTTP metoda
Jedna od kljunih karakteristika RESTful Web Servisa je koritenje HTTP metoda. Za primjer,
HTTP GET metoda je definirana kao metoda koja se koristi od strane klijenta kako bi preuzeo
odreene resurse, dohvatio podatke sa Web servera ili kako bi izvrio upit prema Web serveru
od kojeg oekuje resurse kao odgovor za postavljeni upit.
Osnovni principi dizajna REST Web servisa je da uspostavljaju jedan-na-jedan mapiranje izmeu
CREATE, READ, UPDATE, DELETE (CRUD) operacija i HTTP metoda:
Za kreiranje resursa na serveru koristimo POST metodu
Za preuzimanje resursa sa servera koristimo GET metodu
Za auriranje resursa na serveru koristimo PUT metodu
Za brisanje resursa sa servera koristimo DELETE metodu
Mana ovog dizajna je to se HTTP metode mogu koristiti na neodreen nain. Npr. GET metodu
moemo koristiti i za umetanje novog resursa na server. U tom sluaju URI za GET zahtjev ne
koristimo ispravno ili odudaramo od osnovnih principa dizajna REST Web Servisa. Pogreno
koritenje GET metode je dato u sljedeem primjeru:

GET /adduser?name=Meho HTTP/1.1


U ovom primjeru je koritena GET metoda za dodavanje novog korisnika u bazu podataka, to
nije korektno.
24

Za dodavanje ili kreiranje resursa trabala bi se koristiti POST metoda, pa bi korektno dodavanje
korisnika izgledalo:
POST /users HTTP/1.1
Host: myserver
Content-Type: application/xml
<?xml version="1.0"?>
<user>
<name>Meho</name>
</user>

Na serverskoj strani, zahtjev se procesira tako to se resursi koji se nalaze u tijelu poruke dodaju
kao dijete (child) u/users. Ova relacija izmeu novog entiteta i njegovog roditelja /users je
analogna relaciji izmeu fajla i njegovog roditelj direktorija u datotenom sistemu. Klijent
postavlja relaciju izmeu entiteta i njegovog roditelja te definira URI od entiteta u POST
zahtjevu. Klijent sada moe dohvatiti novi entitet na sljedei nain:
GET /users/Meho HTTP/1.1
Host: myserver
Accept: application/xml

Koritenje GET metode na ovaj nain se preferira, jer GET metoda bi trebala sluiti samo za
dohvatanje podataka.
Ukoliko je potrebno aurirati podatke ve postojeeg resursa, koristi se POST zahtjev na sljedei
nain:
POST /users/Meho HTTP/1.1
Host: myserver
Content-Type: application/xml
<?xml version="1.0"?>
<user>
<name>Suljo</name>
</user>

POST zahtjev se koristi u smislu da on pokazuje na resurs koji je potrebno izmjeniti. Pri tome
nove resurse alje u tijelu POST zahtijeva a ne kao parametre u URI.
Dobra praksa je koristiti imenice u zadanom URI a ne glagole. U RESTful Web Servisu glagoli GET
(dohvatanje), POST (mijenjanje - aktivnost sa popratnom pojavom i promjenom stanja), PUT
(dodavanje - isto uzrokuje promjenu stanja) i DELETE (uklanjanje resursa - isto uzrokuje
promjenu stanja) su ve definisani unutar protokola. Kako bi interfejs ostao generalizovan i
klijenti koristili eksplicitno operacije koje dozivaju, Web servis ne bi trebao definisati vie
glagola i procedura kao to su /adduser ili /updateuser. Isto tako, tijelo poruke se ne bi
trebalo koristiti za dozivanje procedure ve samo za transfer resursa.
25

Stateless protokol protokol bez stanja
HTTP zahtjev je kompletan i nezavisan te takav ne zahtijeva dodatnu logiku na serverskoj strani
prilikom procesiranja zahtjeva. REST Web Servis aplikacija (klijent) u zaglavlju i tijelu HTTP
poruke zahtijeva ukljuuje sve potrebne parametre, kontekste i podatke kako bi se na
serverskoj strani generisao odgovor. Bez stanja, Web Servis postie bolje performanse i
pojednostavljuje dizajn i implementaciju na serverskoj strani jer odsustvo stanja na serveru
otklanja sinhronizaciju sa eksternom aplikacijom.

Slika 9: Dizajn sa stanjima
Na slici 9. se moe primjetiti dodatna logika na serverskoj strani ukoliko se koristi dizajn sa
stanjima. Server mora pratiti prethodno posjeene stranice kako bi znao koja je sljedea
stranica koju je potrebno prikazati klijentu.

Slika 10: Dizajn bez stanja
Ako se koristi dizajn bez stanja rastereuje se server tako to se dodatna logika prebacuje na
stranu klijenta.
26

URI kao struktura direktorija
URI od REST Web Servisa bi trebao biti intuitivan i u takvoj mjeri da bi se mogao predvidjeti.
Struktura URI-ja bi trebala biti jasna, predvidiva i jednostavna za razumjeti. Jedan od naina
kako postii ovaj nivo jednostavnosti jeste da se URI predstavlja kao struktura direktorija u
datotenom sistemu. Ovaj tip strukture je hijerarhija, jedan korijen iz kojeg se granaju ostali
putevi. Za primjer se moe uzeti sljedei URI:
http://www.mojservis.ba/diskusije/teme/{tema}
Korijen, /diskusije, posjeduje vor /teme. Ispod tog vora nalazi se mnotvo tema kao to
su traevi, tehnologija itd., koje pokazuju na odgovarajue diskusije. Dobra praksa je grupisati
resurse po datumu:
http://www.mojservis.ba/diskusije/2013/11/18/{tema}
Prvio dio predstavlja godinu, drugi dio mjesec, a trei dio dan. Ovo je nivo jednostavnosti koji se
eli postii sa ovom vrstom Web Servisa. Ljudi i maine mogu jednostavno konstruisati strukture
kao to su ove jer su one bazirane na pravilima. Sada se moe kreirati uzorak po kojem e teme
biti traene:
http://www.mojservis.ba/diskusije/{godina}/{mjesec}/{dan}/{tema}
Dobre prakse prilikom kreiranja URI:
Ekstenzije na serverskoj strani bi trebale biti skrivene (.jsp, .php, .asp)
Strukture bi trebale biti pisane malim slovima
Koritenje ili _ umjesto blanko karaktera (praznog mjesta)
Izbjegavati stringove koji predstavljaju upite
Umjesto da se samo vrati header 404 u http response, dobra je praksa obezbijediti
stranicu koja e saopiti poruku korisniku.
URI bi trebali biti statini kako bi uslijed izmjene u implementaciji put ostao isti.
Koritenje XML i JSON za prenos podataka
Posljednje ogranienje RESTful Web Servisa jeste format podataka koji se razmjenjuju izmeu
klijenta i servera u tijelu poruke. Klijentu se prua mogunost da izabere tip podataka u HTTP
Accept zaglavlju gdje se unosi vrijednost MIME tipa.
Accept: application/xml

Uobiajeni MIME tipovi za RESTful Web Servise su: JSON, XML i XHTML. To omoguava da servis
koriste raznovrsni klijenti, na raznovrsnim jezicima, na razliitim platformama i na razliitim
ureajima.
27

Praktini primjeri
Kroz prethodna poglavlja analizirane su tehnologije i principi izrade web servisa. U ovom
poglavlju prezentirati e se nekoliko konkretnih primjera web servisa koje su autori ovog
seminarskog rada napravili i koristili tokom svog studija. Primjeri su ilustrativni te se nee
opisivati cijele sisteme, izuzevi odreenih specifinih implementacijskih detalja.
Primjer SOAP ASMX web servisa: eGovernment
eGovernment je projekat raen u okviru kursa OOAD u etvrtom semestru studija. Projekat je
imao za cilj napraviti desktop aplikaciju koja bi komunicirala sa web servisom i na njega se
oslanjala za svu obradu podataka. Neke od mogunosti su kreiranje korisnika, administracija
sistema i korisnika, razmjena poruka izmeu korisnika sistema, online podnoenje tiketa i
njihova obrada, notifikacije itd. Sve funkcije se ostvaruju kroz GUI desktop aplikacije koja
implementira prvi sloj poslovne logike i podnosi zahtjeve web servisu, web servis vri
manipulacije nad bazom podataka i implementira drugi sloj poslovne logike te vraa odgovore
podnositelju zahtjeva.
Koriten je ASMX web servis raen u .net v2 i programski jezik C#. Baza podataka je MySQL u
okviru WAMP, dok se web servis izvrava u okviru IIS, servera koji dolazi uz Windows operativne
sisteme.
Projekat je bio osmiljen iskljuivo kao demonstrator koncepta i nije za realnu primjenu
(sigurnosni aspekti, performanse, arhitektura, neispotovane najbolje prakse, odabrana
kombinacija tehnologija itd.), ali moe posluiti kao primjer izgleda jednostavnog web servisa.
U asmx datoteci nalazi se kd web servisa:
[WebService(Namespace = "http://localhost/eGovernmentWebServis/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[System.ComponentModel.ToolboxItem(false)]
// To allow this Web Service to be called from script, uncomment the following line.
// [System.Web.Script.Services.ScriptService]
public class WebServis : System.Web.Services.WebService {
// private static MySqlConnection konekcija;
private MySqlConnection konekcija;
private Postavke postavke;
public WebServis() {
/*
* Razne postavke koje cemo kasnije koristit kroz program
*/
postavke = Postavke.dajInstancu();
postavke.postavi("mysql_host", "localhost");
postavke.postavi("mysql_username", "root");
postavke.postavi("mysql_password", "");
postavke.postavi("mysql_database", "test");
postavke.postavi("password_length", "8");

/*
* Uspostavimo konekciju koju cemo proslijedjivati dalje kroz program
*/
try {
28

konekcija = new MySqlConnection("Network Address=" + postavke.daj("mysql_host") + ";User
Name='" + postavke.daj("mysql_username") + "';Password='" + postavke.daj("mysql_password") +
"';Database='" + postavke.daj("mysql_database") + "'");
konekcija.Open();
} catch (MySqlException ex) {
Console.WriteLine("Greska: " + ex.Message);
}
}
//primjer jedne metode web servisa koja postavlja informaciju na nivou sistema
[WebMethod]
public Boolean PostaviInformaciju(Informacija i) {
MySqlCommand mcInsert = new MySqlCommand("INSERT INTO informacije(senderID, vrijemeSlanja,
naslovInformacije, tekstInformacije) VALUES (@senderID, @vrijemeSlanja, @naslovInformacije,
@tekstInformacije);", konekcija);
mcInsert.Parameters.AddWithValue("@senderID", i.IDposiljatelja);
mcInsert.Parameters.AddWithValue("@vrijemeSlanja", i.vrijemeSlanja);
mcInsert.Parameters.AddWithValue("@naslovInformacije", i.Naslov);
mcInsert.Parameters.AddWithValue("@tekstInformacije", i.Tekst);
mcInsert.ExecuteNonQuery();
return true;
}
}
}
U okviru desktop aplikacije potrebno je dodati referencu na servis (pri tome servis mora biti
deployed tj. pokrenut i mora se koristiti njegov pristupni URL da bi desktop aplikacija postala
"svjesna" njegovih funkcionalnosti kroz itanje automatski generiranog WSDL dokumenta, a
koje e automatski pretvoriti u odgovarajue metode WebServis klase).
// Uspostavimo konekciju koju cemo proslijedjivati dalje kroz program
try {
webServis = new WebServis();
} catch (Exception ex) {
MessageBox.Show("Cudne se greske dogadjaju :o");
}
Prethodnim kdom provjerava se da li je referenca na web servis dobro postavljena. Nakon
toga webServis objekat raspolae svim metodama koje su ranije specificirane kao WebMethod
u WebService klasi.
Da bi se iskoristila prethodno deklarirana WebMetoda kroz desktop aplikaciju, koristi se sljedei
kd.
private void finalizirajSlanjeInformacije(object sender, EventArgs e)
{
Informacija i = new Informacija();
i.IDposiljatelja = _admin.IDosobe; i.Naslov = _si.dajNaslov; i.Tekst = _si.dajTekst;
i.vrijemeSlanja = DateTime.Now;
if (_ws.PostaviInformaciju(i))
{
MessageBox.Show("Informacija je uspjesno objavljena!");
}
else
{
MessageBox.Show("Doslo je do neocekivane greske pri slanju :(");
}
}
29


Vano je napomenuti da klase koje se prenose SOAP protokolom izmeu desktop aplikacije i
web servisa moraju zadovoljavati odreene kriterije, npr. moraju imati konstruktor bez
parametara, javno raspoloive propertije to su u biti standardni zahtijevi koji su prisutni npr. i
kroz Javu (tzv. JavaBeans).
Potivanjem tih principa omoguena je serijalizacija i deserijalizacija objekata u formate
pogodne za prijenos putem mree tj. objekte se moe automatski spasiti u tekstualni format iz
kojeg ih je kasnije mogue opet automatski jednoznano rekonstruirati.
30

Primjer RESTful web servisa u Java programskom jeziku: jParking
jParking je sloeni sistem za upravljanje parkingom raen u okviru kursa Softver inenjering u
estom semestru studija RI. Sistem se sastojao od desktop aplikacije, aplikacija na
mikrokontrolerima i Raspberry Pi mikroraunarima i RESTful web servisa za upravljanje
sistemom i rad sa podacima. Sve komponente meusobno komuniciraju posredstvom web
servisa.
Sistem je razvijan upotrebom Java programskog jezika i Jersey frameworka za razvoj RESTful
web servisa po JAX-RS specifikaciji. Baza je MySQL, dok se web servis nalazi na Glassfish serveru
kao najbrem besplatnom rjeenju.
U ovom sluaju iskoriteni su napredniji patterni za rad sa bazom. Obraditi e se primjer prijave
korisnika na sistem.
Za bazu su iskoriteni DAO patterni, s tim da je jedan od nedostataka to to su podaci za pristup
bazi hardkodirani a ne nalaze se u konfiguracijskoj datoteci:
public class DAOFactory {
private static final String Driver= "com.mysql.jdbc.Driver";
private static final String DBURL= "jdbc:mysql://jparking.mooo.com:3306/mydb";
private static final String dbuser= "jufka";
private static final String dbpass= "jufka";

public static Connection c;

public static void connect() throws Exception {
try {
Class.forName(Driver);
c = DriverManager.getConnection(DBURL, dbuser, dbpass);
} catch (Exception e) {
throw new Exception("Neuspjelo povezivanje sa bazom.");
}
}

public static void disconnect() throws Exception {
try {
c.close();
} catch (Exception e) {
throw new Exception("Neuspio prekid veze sa bazom.");
}
}

public static KorisnikDAO getKorisnikDAO() throws Exception {
return new KorisnikDAO(c);
}
}
public class KorisnikDAO {
private final Connection c;
private final PreparedStatement qLogin;

public KorisnikDAO(Connection c) throws Exception {
this.c = c;
31

qLogin = c.prepareStatement("SELECT * FROM korisnici WHERE username=?
AND password=md5(?)");
}

public Korisnik selectLoginDataKorisnik(String username, String password)
throws Exception{
qLogin.setString(1, username);
qLogin.setString(2, password);
ResultSet rs = qLogin.executeQuery();
if (rs.next()==false)
throw new Exception();
Korisnik k = ucitajKorisnikaIzResultSeta(rs);
rs.close();
return k;
}
}

Sada kada je prisutna podatkovna osnova (klase su obavezno implementirane kao JavaBean)
razmatra se korisnika kao resurs kojim sistem raspolae. Autentifikacija je implementirana na
trivijalan nain budui da se komunikacija predvieno obavlja putem intraneta. Resurs se nalazi
na putanji host:port/[web.xml specificirani path]/korisnici. U ovom sluaju je to
host:port/wsdata/korisnici. Resurs prima username i password kroz header HTTP requesta i
proizvodi XML serijaliziranu instancu korisnika ili null.

@Path("/korisnici")
public class KorisniciResurs {
@Context
UriInfo uriInfo;
@Context
Request request;


@GET
@Path("login")
@Produces(MediaType.APPLICATION_XML)
public Korisnik prijaviNaSistem(@HeaderParam("username")String username,
@HeaderParam("password")String password) throws Exception{
try{
DAOFactory.connect();
Korisnik k = KontrolerPristupa.getKorisnik(username, password);
Logger.ZabiljeziAkciju(k.getId(), "Prijava na sistem.");
DAOFactory.disconnect();
return k;
}
catch(Exception e){
e.printStackTrace();
return null;
}
}
}

32

Uz importovanje odgovarajuih klasa iz Jersey biblioteke sada se web servis moe konzumirati
na sljedei nain:
ClientConfig config = new DefaultClientConfig();
Client client = Client.create(config);
service= client.resource(UriBuilder.fromUri("http://localhost:8080/jParkingWSData"
).build());

Dok se akcija prijaviNaSistem nad resursom korisnik poziva na sljedei nain:
Korisnik k= service.path("wsdata").path("korisnici").path("login").header("username",
username).header("password",password).accept(MediaType.APPLICATION_XML).get(Korisnik.
class);

Rad sa listama i Boolean tipovima je problematiniji zbog nejednoznanosti predstavljanja tih
tipova u XML-u. Slijedi primjer resursa "svi korisnici" i dobijanja liste svih korisnika na klijentu:
@GET
@Path("svi")
@Produces(MediaType.APPLICATION_XML)
public GenericEntity<List<Korisnik>>
getAllKorisnici(@HeaderParam("username")String username,
@HeaderParam("password")String password) throws Exception {
try{
DAOFactory.connect();
int idKorisnikaAdmina = KontrolerPristupa.getID(username,
password, Korisnik.Privilegije.Administrator);
if (idKorisnikaAdmina!=-1){
List<Korisnik> korisnici =
DAOFactory.getKorisnikDAO().selectSviKorisnici();
DAOFactory.disconnect();
return new GenericEntity<List<Korisnik>>(korisnici){};
}
return null;
}
catch(Exception e)
{
e.printStackTrace();
return null;
}
}
Dobijanje svih korisnika:
List<Korisnik> korisnici=
service.path("wsdata").path("korisnici").path("svi").header("username",
hardcodedUsername).header("password",hardcodedPassword).accept(MediaType.APPLICATION_
XML).get(new GenericType<List<Korisnik>>() {});

33

Primjer konzumacije RESTful web servisa kroz Android
Ukoliko se eli kreirati klijenta na Android aplikaciji za komunikaciju sa RESTful web servisom
potrebno je da se u projektu kreira sljedeu klasu:
public class WebServiceRequest {
private static final int CONN_TIMEOUT = 5000;
private static final int SOCKET_TIMEOUT = 10000;
private static final String TAG = "WebServiceTask";
private ArrayList<NameValuePair> params;

public static final int POST_TASK = 1;
public static final int GET_TASK = 2;
public static final int PUT_TASK = 3;
public static final int DELETE_TASK = 4;

public WebServiceRequest(int taskType) {
this.taskType = taskType;
params = new ArrayList<NameValuePair>();
}


public String Execute (String url) {
String result = "";
HttpResponse response = doResponse(url);
result = inputStreamToString(response.getEntity().getContent());
return result;
}

public void AddNameValuePair(String name, String value) {
params.add(new BasicNameValuePair(name, value));
}

HttpParams getHttpParams() {
HttpParams htpp = new BasicHttpParams();
HttpConnectionParams.setConnectionTimeout(htpp, CONN_TIMEOUT);
HttpConnectionParams.setSoTimeout(htpp, SOCKET_TIMEOUT);
return htpp;
}

private HttpResponse doResponse(String url) {
HttpClient httpclient = new DefaultHttpClient(getHttpParams());
HttpResponse response = null;

try {
switch (taskType) {

case POST_TASK:
HttpPost httppost = new HttpPost(url);
httppost.setEntity(new UrlEncodedFormEntity(params));
response = httpclient.execute(httppost);
break;
case GET_TASK:
HttpGet httpget = new HttpGet(url);
response = httpclient.execute(httpget);
break;
case PUT_TASK:
HttpPut httpput = new HttpPut(url);
response = httpclient.execute(httpput);
break;
case DELETE_TASK:
HttpDelete delete = new HttpDelete(url);
httpclient.execute(delete);
break;
}
} catch (Exception e) {
Log.e(TAG, e.getLocalizedMessage(), e);
34

}
return response;
}
}

Ova klasa sadri osnovne metode za slanje zahtjeva prema serveru i dohvatanje odgovora sa
servera. Slijedi primjer kako poslati zahtjev:
WebServiceRequest wst = new WebServiceRequest(WebServiceRequest.POST_TASK);
wst.AddNameValuePair("username", username);
wst.AddNameValuePair("password", password);
String odgovor = wst.Execute(http://www.mojservis.ba/servis/login);

Iz primjera se vidi da konstruktor prima samo jedan parametar i to tip zahtijeva. Zahtijev moe
biti POST, GET, PUT ili DELETE. Zatim se dodaje parametre sa funkcijom AddNameValuePair(). U
konkretnom sluaju dodaje se dva parametra: username i password. Da bi se dobio odgovor
poziva se funkciju Execute(String url) sa navedenom putanjom. Ova funkcija nakon dohvatanja
kompletnog HTTP odgovora vadi podatke iz tijela poruke te kompletno tijelo poruke vraa kao
string.
Odgovor sa servera moe biti u XML ili JSON formatu kako je opisano u prethodnom tekstu.
Ukoliko je odgovor u JSON formatu moe ga se parsirati na sljedei nain:
JSONObject jso = new JSONObject(odgovor);
String firstName = jso.getString("firstName");
String lastName = jso.getString("lastName");
String email = jso.getString("email");

Treba napomenuti da ovakav pristup moe izazvati zamrzavanje ekrana prilikom dohvatanja
vee koliine podataka jer dohvatanje podataka se vri direktno unutar aplikacije u glavnoj niti
programa to troi procesorsko vrijeme glavnog programa. Da bi se rasteretilo glavnu nit i
sprijeilo zamrzavanje ekrana potrebno je metodu Execute() pozvati u zasebnoj niti odvojeno
od glavne niti kako bi glavna nit nesmetano aurirala ekran i rukovala sa dogaajima.
35

Primjer RESTful web servisa u Ruby on Rails: etf.ba v2
ETF.ba verzija 2 je studentski portal pisan upotrebom Ruby on Rails frameworka u okviru kursa
Baze podataka u prvom semestru drugog ciklusa studija RI. Sistem se sastojao od web interfejsa
i android aplikacije. Da bi se omoguila integracija sa android aplikacijom, sistem je morao
pruiti interfejs android aplikaciji u vidu RESTful web servisa. Web servis je implementiran na
nain da se u postojeim akcijama unutar odgovarajuih kontrolera implementirala druga logika
obrade zahtjeva bazirana na samom formatu zahtjeva. Zbog svoje jednostavnosti, kao format
serijalizacije odabran je JSON.
U nastavku e zbog jednostavnosti biti prikazan kod za web servis vezan samo za osnovne
operacije nad korisnikom.
Operacije definisane nad korisnikom, a koje su izloene android aplikaciji su:
Prijava,
odjava,
pregled linih podataka,
pregled podataka drugog korisnika (omoguena samo administratorima),
izmjena linih podataka,
izmjena podataka drugog korisnika (omoguena samo administratorima).
Iz tog razloga, po specifikaciji REST servisa definisani su slijedei zahtjevi:
POST login - prijava korisnika
GET logout - odjava korisnika
GET user - dobavljanje linih podataka
GET user/{id} - dobavljanje podataka za korisnika
POST user - izmjena linih podataka
POST user/{id} - izmjena podataka za korisnika
Definisani zahtjevi se moraju navesti u sklopu Rails aplikacije unutar datoteke config/routes.rb
to otprilike izgleda ovako:

...
post "login" => "user#login_post"
get "logout" => "user#logout", :as => :logout

get "user" => "user#profile", :as => :profile
get "user/:user_id" => "user#profile"

post "user" => "user#edit"
post "user/:user_id" => "user#edit"
...
Analizom navedenih putanja, moe se primijetiti da sve akcije obavlja kontroler sa nazivom
User, koji izmeu ostalog sadri akcije login_post, logout, profile, edit, koje obrauju prethodno
navedene zahtjeve.
36

U primjeru User kontrolera koriten je koncept filtera koje Rails framework prua, te je
napravljena metoda require_login koja za akcije unutar User kontrolera provjera da li je
korisnik prijavljen na sistem, te odluuje da li e dozvoliti korisniku da izvri zadanu akciju. Njen
izvorni kod je dat u nastavku:
def require_login
if !is_logged_in?
respond_to do |format|
format.html {
session[:return_to] = request.fullpath if request.get?
redirect_to login_path
return
}

format.json {
username = params[:username]
password = User.get_hash(params[:password])

user = User.where(username: username, password: password).first unless username.nil? or
password.nil?

if user.nil?
render :json => {error: true, message: 'Neispravni pristupni podaci.'}
return
end

flash[:user] = user
}
end
end
end

Analizom navedene metode moe se primijetiti da postoje razliite logike za zahtjeve koji trae
HTML format i zahtjeve koji trae JSON format. Ta dva formata zapravo korespondiraju web
interfejsu i web servisu respektivno. Dakle, web servis u Rails aplikaciji je jednostavno
realizovan upotrebom respond_to metode koja omoguava izvravanje razliite logike za
razliite traene formate sadraja. Traeni format se navodi tako to se nakon URL-a navede
ekstenzija kao na primjer: http://www.etf.ba/login.json
Svi zahtjevi ka web servisu koji zahtijevaju da korisnik mora biti prijavljen, moraju kao
parametre proslijediti korisniko ime i lozinku korisnika, koje se u ovoj metodi unutar
formats.json bloka provjeravaju i prosljedjuju dalje do prave akcije, ili u sluaju da korisniki
podaci nisu ispravni, korisniku se alje JSON objekat koji sadri polje error koje signalizira da se
desila greka, te polje message koje sadri ljudima prepoznatljiv opis greke koja se dogodila.
Kako je fokus ovog seminarskog rada na principu kreiranja web servisa, a ne na samoj logici
razvijenog web servisa, u nastavku je dat izvorni kod User kontrolera bez detaljnog objanjenja.
class UserController < ApplicationController
before_filter :require_login, except: [:login_post]

def login_post
37

username = params[:username]
password = User.get_hash(params[:password])

user = User.where(username: username, password: password).first unless username.nil? or password.nil?

respond_to do |format|
format.html {
# logika za obradu html zahtjeva
}

format.json {
# web servis logika

if user.nil?
render :json => { :error => true, :message => "Neispravni pristupni podaci."}
return
else
render :json => user
return
end
}
end
end

def edit
respond_to do |format|
format.html { }

format.json {
if flash[:user].nil?
user = session[:user]
else
user = flash[:user]
end

if params[:user_id]
# user wants to edit some other user
if user.user_privilege.name == Rails.application.config.PRIVILEGE_ADMINISTRATOR
# and user is an admin
target_user = User.where(id: params[:user_id]).first
if target_user.nil?
# and target user does not exist
render :json => {error: true, message: "Navedeni korisnik ne postoji."}
return
else
#and target user exists
target_user.nickname = params[:new_nickname] unless params[:new_nickname].nil?
target_user.password = User.get_hash(params[:new_password]) unless
params[:new_password].nil?
target_user.email_alt = params[:new_email] unless params[:new_email].nil?

new_user_type = UserType.where(id: params[:new_user_type]).first
target_user.user_type = new_user_type unless new_user_type.nil?

new_user_privilege = UserPrivilege.where(id: params[:new_user_privilege]).first
target_user.user_privilege = new_user_privilege unless new_user_privilege.nil?

if target_user.valid?
# and changes are valid
target_user.save
render :json => target_user
return
else
# and changes are invalid
render :json => {error: true, message: "Proslijedjeni podaci nisu validni."}
return
end
end
else
38

# and user is not an admin
render :json => {error: true, message: "Nemate pravo pristupa."}
return
end
else
# user wants to edit his profile
user.nickname = params[:new_nickname] unless params[:new_nickname].nil?
user.password = User.get_hash(params[:new_password]) unless params[:new_password].nil?
user.email_alt = params[:new_email] unless params[:new_email].nil?

if user.valid?
# and changes are valid
user.save
render :json => user
return
else
# and changes are invalid
render :json => {error: true, message: "Proslijedjeni podaci nisu validni."}
return
end
end
}
end
end

def profile
respond_to do |format|
format.html { }
format.json {
user = flash[:user]
if params[:user_id]
# user wants to view some other user
if user.user_privilege.name == Rails.application.config.PRIVILEGE_ADMINISTRATOR
# and user is an admin
target_user = User.where(id: params[:user_id]).first
if target_user.nil?
# and target user does not exist
render :json => {error: true, message: "Navedeni korisnik ne postoji."}
return
else
#and target user exists
render :json => target_user
return
end
else
# and user is not an admin
render :json => {error: true, message: "Nemate pravo pristupa."}
return
end
else
# user wants to view his profile
render :json => user
return
end
}
end
end
end
39

Primjer zahtjeva prijave korisnika:
POST http://localhost:3000/user.json HTTP/1.1
Host: localhost:3000
Content-Type: application/x-www-form-urlencoded

username=ahajdarevi2&password=098C2F1E56D84

Odgovor web servisa:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-Ua-Compatible: IE=Edge
Etag: "9b144eb192b49ac95c89ab2561a05306"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: 1584b3633832690c50f26dc297f1f478
X-Runtime: 0.045002
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-11-10)
Date: Sun, 17 Nov 2013 19:44:56 GMT
Content-Length: 294
Connection: Keep-Alive

{"avatar_path":null,"created_at":"2013-11-
17T18:47:17Z","email_alt":null,"email_main":"ahajdarevi2@etf.unsa.ba","id":2,"is_banned":false,"name":"Adn
an","nickname":"c0de","surname":"Hajdarevi","updated_at":"2013-11-
17T18:57:03Z","user_privilege_id":1,"user_type_id":1,"username":"ahajdarevi2"}

Odgovor web servisa na zahtjev prijave korisnika sa pogrenim podacima:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-Ua-Compatible: IE=Edge
Etag: "868f152fc0ea358aeac346e4d2e9758f"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: db376e695c3445032327f9cbe9b40d1c
X-Runtime: 0.015001
Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-11-10)
Date: Sun, 17 Nov 2013 19:49:59 GMT
Content-Length: 55
Connection: Keep-Alive

{"error":true,"message":"Neispravni pristupni podaci."}
40

Zakljuak
U okviru ovog seminarskog rada dat je kratak uvod u web servise i njihovu upotrebu.
Analizirane su servisno orijentirane arhitekture kao framework koji sadri pravila i smjernice za
dizajn i implementiranje servisa kao zaokruenih cjelina koje se moe na optimalan nain
koristiti u dinaminom okruenju. Opisane su bazne tehnologije na kojima se web servisi
zasnivaju: protokoli razmjene poruka (SOAP i REST zasnovani servisi) kao i formati za prijenos
podataka u porukama (XML i JSON). Izloene su njihove prednosti i nedostaci kako bi se moglo
donijeti odgovarajue odluke o njihovoj upotrebi u konkretnim projektima. Dati su i praktini
primjeri sa isjecima kda koji pokrivaju osnove izloene tematike.