Š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.

Tipovi web servisa

Glavni protokol za transport podataka izmedju web servisa i klijenta je HTTP iako je moguće je koristiti i druge protokole. Format za prenos podatak je XML ili JSON.

a) Big Web Services (tzv. SOAP bazirani servisi)

soap poruka

Ovi servisi slede SOAP standarde a podaci se prenose u XML formatu a opisani su WSDL. Korišćenje SOAP protokola omogućava komunikaciju izmedju aplikacija na različitim operativnim sistemima i različitim tehnologijama tako što aplikacije razmenjuju poruke “dogovorenog” formata.
Postoji nekoliko različitih tipova poruka u SOAP-u, najpoznatiji je poziv udaljenim procedurama (tzv. Remote Procedure Call – RPC). To je tip poruka u kojem jedan čvor u mreži (klijent) šalje zahtev drugom čvoru (server), nakon čega server vraća odgovor na primljeni zahtev. Ovaj protokol je naslednik je XML-RPC protokola. Koristii ista pravila za transport ali ima drugačiju strukturu poruke.

Oblasti u kojima se SOAP bazirani serivisi dobro “snalaze” su:

  • kod formalnih ugovora kada obe strane trebaju da se slože oko formata za razmenu informacija
  • kod operacija koje koriste stanja

Mana SOAP baziranih servisa je kompleksnost i prevelika „opširnost“ pri korišćenju XML-a, mada ova mana ne sprečava Microsoft i IBM da ga veoma često koriste. U mane se takodje smatra potrošnja resursa da bi se parsirao XML.

SOAP (Simple Object Access Protocol) je komunikaciski protokol koji se koristi za opis poruka izmedju aplikacija. SAOP protokol definiše i propisuje format poruka za komunikaciju. SOAP poruka je običan XML dokument koji se sastoji iz sledećih elemenata:

  • Envelope elemenat (identifikuje XML dokumenat kao SAOP poruku) je obavezan deo
  • Zalavlje (header) koji je opcioni deo
  • Telo (body) je obavezni deo i nosi informacije (parametre) zahteva i vraća rezultate tj.odgovor Web serisa.
  • Fault element koji je opcioni i pruža informacije o tome šta treba uraditi ukoliko dodje do greške prilikom procesuiranja poruke

b) RESTful web servisi

Ovi servisi su jednostavnije integrisani sa HTTP-om od SOAP servisa, ne zahtevaju XML poruke ili WSDL opise servisa. Danas se RESTfull izdvojio kao dominantan mrežni servis, potisnuo je SOAP i WSDL jer je značajno jednostavniji za korišćenje.

Karakteristike REST API-ja

REST je akronim za “Representational State Trasfer” i odnosi se na način/principe kreiranja API-ja. Podaci se najčešće prebacuju u JSON formatu mada je dostupan i XML i YAML format. API se zasniva na REST arhitekturi te je veoma fleksibilan i jednostavan za razumevanje.
Kod ovog tipa API-ja, resursi (npr. statičke strane, fajlovi, podaci iz baze…) imaju sopstveni URL ili URI koji ih identifikuju, a pristup do resursa je definisan tako da svaki poziv čini jednu akciju (kreira, čita, menja ili briše podatke).
Isti URL se koristi za sve operacije ali se menja HTTP metod koji definiše vrstu operacije. REST koristi “CRUD like” HTTP metode kao što su: GET, POST, PUT, DELETE, OPTIONS.

non rest api

RESTful servisi imaju sledeće osobine i karakterisitike:

  • Mogućnost keširanja (Cacheable)
  • Uniformni interfejs (Uniform interface URI)
  • Izričito korišćenje HTTP metoda
  • Transfer XML i/ili JSON
  • Nepostojanje stanja (“stateless”), što znači da server ne pamti nikakve podatke o klijentu, odnosno da klijent sa svakim zahtevom mora slati sve potrebne informacije za razumevanje i obradu tog zahteva, i ne oslanjati se na to da će ga server “prepoznati” (odnosno iskoristiti informacije iz prethodnih zahteva istog klijenta). Pogledajte sliku ispod:
    stateless rest api

Primena RESTfull servisa

RESTfull servisi se koriste:

  • kod ograničenog propusnog opsega i resursa (povratna informacija može biti u bilo kom obliku)
  • kod operacija koje ne koriste stanja (ukoliko neka operacija treba da bude nastavljena onda REST nije pravi pristup i SOAP verovatno predstavlja bolje rešenje)
  • kod situacija gde je moguće keširanje (ukoliko informacija može biti keširana zbog operacija koje ne koriste stanja onda je ovaj pristup odličan)

Prednosti RESTfull servisa

Odlike RESTfull servisa su:

  • jednostavnost
    Klijenti koji pozivaju REST servise ne moraju da formatiraju zahteve po SOAP specifikaciji i ne moraju da parsiraju SOAP odgovor kako bi iz njega izvukli rezultat.
  • fleksibilnost formata vraćenih podataka
    Format u kome se podaci vraćaju nije unapred definisan i zavisi od samog servisa. Klijenti mogu da zatraže podatke u formatu koji im najviše odgovara, za razliku od SOAP formata koji iako je standardizovan mora da se parsira. Pa tako JavaScript može dobiti podatke u JSON formatu koji lako može da pročita, a RSS čitač u RSS-XML formatu koji može da prikaže.
  • korišćenje postojeće mrežne infrastrukture
  • brzo savladavanje tehnike

Na sledećoj slici imate primer api-ja koji nije prilagodjen REST arhitekturi:

non rest api

NAPOMENA:
REST nije protokol kao SOAP već je koncept koji se bazira na promeni stanja klijenta i sve akcije se obavljaju u trenutku promene tog stanja, s mogućnošću vraćanja na neko od prethodnih stanja.

c) Web servisi zasnovani na POX (Plain Old XML)

Postoji rastući trend kod pragmatičnih programera da koriste Plain Old XML uz “REST like” URL i najbolje iz SOAP protokola. Ovaj servis koristi “sirov” XML za prenos podataka, a GET i POST metode za komunikaciju. Kada se kaže da koristi sirov XML misli se nije obavijen nikakvim drugim omotom (eng envelope) nekog message protokola. Ovaj tip servisa je jednostavniji i brži od SOAP servisa, a zadržao je “strongly-typed API” koji je najveća prednost SOAP servisa.

Podelite:

2 Responses to “Web servisi (osnove)”

  1. Dejan

    Pozdrav.
    Interesuje me dodatno pojasnjenje za ovo:”kod operacija koje ne koriste stanja (ukoliko neka operacija treba da bude nastavljena onda REST nije pravi pristup i SOAP verovatno predstavlja bolje rešenje)”. Sta tacno to podrezumeva? Da li moze neki primer pa da bi mogao da razumem tu razliku izmedju SOAP i REST-a?

    • Dragoljub

      Dejane, hvala na interesovanju i komentaru. Nepostojanje stanja (“stateless”) podrazumeva da server ne pamti nikakve podatke o klijentu, odnosno da klijent sa svakim novim zahtevom mora slati sve potrebne informacije za razumevanje i obradu tog zahteva, i ne može se osloniti na to da će ga server “prepoznati”, odnosno iskoristiti informacije iz prethodnih zahteva istog klijenta. Dodao sam i novu sliku koja bi trebala da pomogne pri razumevanju šta znači “stateless” tj. “ne korištenje stanja”

Ostavite komentar