Web servisi (osnove)

Šta su web servisi?

Web servis je aplikacija smeštena na nekom serveru, koja je pored osnovne namene dizajnirana da podrži interakciju izmedju dve mašine preko mreže i omogući razmenu informacija izmedju njih. Smatra se da je svaki servis i web servis ako je:

  • Dostupan preko interneta ili (interne mreže)
  • Koristi stadndardizovan sistem poruka
  • Prepoznatiljv je od strane mehanizma za pretragu
  • Nije vezan za operativni sistem ili programski jezik
Pretraga web servisa

Web Servisi se objavljuju na jedinstvenoj lokaciji gde se nude kao usluge. UDDI (Universal Description, Discovery and Integration) predstavlja centralizoanu lokaciju koja obezbeđuje mehanizam za registrovanje i pronalaženje Web servisa. UDDI koristi SOAP za komunikaciju i omogućava klijentima da pronađu servis, kao i serveru da ga objavi.

Servisi mogu biti zatvoreni (privatni) ali i javno dostupni. Listu javno dostupnih servisa možete pogledati na više sajtova:

Opis web servisa

Web servisi imaju mogućnost da opišu sebe, a za opis servisa se koristi WSDL (eng. Web Service Description Language). WSDL je napisan XML-om i sadrži informacije gde se web servis nalazi i koji protokol za komunkaciju koristi.

Saradnja sa GUI aplikacijom

Web servisi u saradnji sa GUI aplikacijom su nešto izmedju web i desktop aplikacije. Web servis na serveru daje funkcionalnost i podatke a desktop aplikacija samo daje prilagodljivi grafički interfejs koji popunjava sa dobijenim podacima od servisa. Web servis u saradnji sa GUI aplikacijom je fleksibilniji od web aplikacije jer korisnik može da prilagodi izgled aplikacije na klijentu dok korisnik web aplikaciie mora da koristi web browser i nema uticaja na to kako će aplikacija izgledati na ekranu.

Prednosti u odnosu na web aplikaciju:
  • Štedljiviji su po pitanju opterećenja mreže i resursa servera jer pri komunikaciji šalju samo odgovor dok web aplikacije pored odgovora šalju i HTML sa formom i opisom kako ogovor treba da bude prikazan. Web servisi su idealni su za “male” uredjaje koji nisu PC tj. mobilne Pocet PC… jer je na takvom uredjaju instalirana samo front-end aplikacija a teži deo se odradjuje na serveru.
  • Lakši su za razvoj, testiranje i održavanje. Kod Web aplikacije pored neophodne funkcionalnosti je potrebno istestirati i dizajn na svim browserima i platformama dok kod web servisa autor brine samo o funkciji dok o prikazu brine klijentska aplikacija.

klijent server

Kod servisa se komunikacija odvija izmedju klijenta i servera tako što klijent pošalje zahtev serveru koji onda server taj zahtev primi i obradi ga pa u odnosu na njega formira odgovor koji zatim pošalje nazad klijentu. Klijent-server stil arhitekture odvaja problematiku dve strane komunikacijskog kanala, što znači da klijentsku stranu uopšte ne zanima način čuvanja informacija na serveru jer uvijek postoji uniforman način pristupa tim resursima. S druge strane, server je nezavisan od klijenta i ne zanima ga kako je implementirano korisnički interfejs niti u kojem je stanju pojedini klijent, čime je serverska strana znatno pojednostavljena. Ovime je postignuta njihov nezavisnost i lakše razdvojeno razvijanje obe strane, odnosno moguće je npr. unaprediti serversku stranu ili potpuno izmeniti njegovu logiku, a da klijent to uopšte ne primieti dok god je način pristupa resursima isti.

Šta je API?

Da bi se ostvarila komnikacija izmedju dva sistema potrebno je da imaju “tačku” za kontakt, tzv. interfejs. Interfejs je posrednik (veza) pri komunikaciji izmedju dva odvojena sistema koji zajedno rade i može biti:

  • Hardverski interfejs (npr. volan, gas i menjač su “tačke pristupa vozilu” i predstavlju posrednika između automobila i osobe koja upravlja sa njim)
  • Programski interfejs tzv. “API” koje predstavlja “tačke pristupa” pri komunikaciju izmedju dva programa

Rad sa servisima podrazumeva da se resursima pristupa na udaljenom serveru (pristup je putem interenet mreže), ovakva mrežna komunikacija sa sobom donosi problem pristupa i prenosa složenih struktura podataka kao i same organizacije resursa na serveru. Programeri su tokom vremena kreirali komunikaciju izmedju dva programa na razne načine tj. pravli različite tipove API-ja ali su u jednom trenutku standardizovali način komunikacije tj. napravili su skup pravila koja mrežne aplikacije trebaju pratiti pri medjusobnoj komunikaciji (npr. jedan od takvih standardizovanih api-ja je “REST API”).
Ono na šta moramo obratiti pažnju je da kada se jednom definiše API i pusti u “promet”, u slučaju da je nakon nekog vremena potrebno napraviti izmene, nije pametno menjati do sada postavljene “end point-e” jer bi bilo u najmanju ruku neljubazno prisiljavati potrošače API-ja da menjaju već izradjene programe da bi se prilagodili na promenu. Kada se napravi promena uvek treba težiti da nastavite s podrškom za postojeća svojstva (end point-e), a da za promene dodate nova svojstva umesto menjanja postojećih.

Continue reading…