Izgradnja web servisa REST način

Source: http://xfront.com/REST-Web-Services.html

Roger L. Costello

Prvo ću dati kratak uvod da se odmori, a zatim opisati kako izgraditi web servisa u REST stilu.

Što je REST?

REST je termin skovao Roy Fielding u doktorirao disertacija [1] opisati arhitekturu stil umreženih sistema. Ostatak je akronim stoji za Reprezentativna Stanje Transfer.

Zašto se zove Reprezentativna Stanje Transfer?

Web se sastoji od resursa. Resurs je bilo predmet interesa. Na primjer, Boeing Aircraft Corp može odrediti 747 resursa. Klijenti mogu pristupiti taj resurs s ovom URL:

http://www.boeing.com/aircraft/747

Reprezentacija resursa se vraća (npr Boeing747.html). Predstavljanje stavlja klijentske aplikacije u stanje. Rezultat klijenta prolazili hipervezu u Boeing747.html je još jedan resurs se pristupa. Novi predstavljanje stavlja klijentske aplikacije u još jednu državu. Dakle, aplikacija klijent promjene (transferi) država sa svake reprezentacije resurs -> Reprezentativna Stanje Transfer!

Ovdje je objašnjenje Roy Fielding značenja Representational države transfera:
“Representational država Transfer je namijenjen dočarati sliku o tome kako dobro osmišljen Web aplikacija ponaša: mrežu web stranica (virtualni država-mašina), gdje korisnik napreduje kroz aplikaciju odabirom poveznice (država prelazi), što je rezultiralo sljedećoj stranici (koja predstavlja sljedeći stanje aplikacije) se prenosi do korisnika i donosi za njihovo korištenje.”

Motivacija za REST

Motivacija za ostatak je za snimanje karakteristika web što je Web uspješan. Nakon toga ove karakteristike se koriste za usmjeravanje evolucije Web.
REST – arhitektonski stil, nije standardni

REST nije standard. Nećete vidjeti W3C gašenju specifikaciju REST. Nećete vidjeti IBM ili Microsoft ili Sun prodaje alata REST programera. Zašto? Jer ostalo je samo arhitektonski stil. Ne možete taložili taj stil. Možete shvatiti samo to, i dizajn Web usluga u tom stilu. (Analogno klijent-server arhitekture. Nema klijent-server standard.)

Dok ostatak nije standard, to čini standarde korištenja:

  • HTTP
  • URL
  • XML / HTML / GIF / JPEG / etc (Resource Izjave)
  • text / xml, text / html, image / gif, image / jpeg itd (MIME tipova)

Klasičan sistem REST

Web je REST sistemu! Mnogi od tih Web usluga koje ste koristili ove mnogo godina – knjiga-naručivanje usluge, pretraživanje, online rječnik usluge, itd – su REST-based Web usluge. Avaj, ste koristili REST, izgradnju REST usluge i nisi ni znao.

Ostatak se bavi “veliku sliku” Web. Ona se ne bavi detaljima implementacije (npr koristeći Java servletima ili CGI za implementaciju web usluga). Dakle, pogledajmo na primjer stvaranja web servisa od ostatka “veliku sliku” perspektive.

Dijelova Depot web servici

Dijelova Depot, Inc (fiktivna firma) je rasporedila neke web servisa da omogući svojim klijentima:

  • dobiti popis dijelova
  • dobiti detaljne informacije o određenom dijelu
  • dostaviti narudžbenicu (PO)

Razmotrimo kako svaka od tih usluga su implementirane u ugodan način.

Dobiti dijelovi popis

Web uslugu stavlja na raspolaganje URL na popis dijelova resursa. Na primjer, klijent će koristiti ovaj URL da biste dobili popis dijelova:

http://www.parts-depot.com/parts

Imajte na umu da “kako” web servisa generira popis dijelova je potpuno transparentan za klijenta. Svi klijent zna je da će, ako on / ona podnosi iznad URL zatim dokument koji sadrži popis dijelova se vraća. Od početka primjene je transparentan klijentima, Parts Depot je slobodno mijenjati temeljne realizaciju ovog resursa bez uticaja na klijente. Ovo je labav spojnice.

Evo dokument koji klijent prima:

<?xml version="1.0"?>
<p:Parts xmlns:p="http://www.parts-depot.com" 
         xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>
      <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/>
      <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/>
      <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/>
</p:Parts>

[Pretpostavimo da se kroz sadržaj pregovora servisa utvrdi da klijent želi zastupljenost kao XML (za mašinsku obradu-to-machine).] Imajte na umu da je lista dijelova ima veze da biste dobili detaljnije informacije o svakom dijelu. Ovo je ključna karakteristika odmora. Klijent transferi iz jedne države u narednih ispitujući i izbora između alternativnih URL-ova u dokumentu odgovor.

Dobiti detaljne dio podataka

Web uslugu stavlja na raspolaganje URL za svaki dio resursa. Primjer, evo kako klijent zahtijeva dijela 00345:

http://www.parts-depot.com/parts/00345

Evo dokument koji klijent prima:

<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"   
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part-ID>00345</Part-ID>
      <Name>Widget-A</Name>
      <Description>This part is used within the frap assembly</Description>
      <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
      <UnitCost currency="USD">0.10</UnitCost>
      <Quantity>10</Quantity>
</p:Part>

Opet posmatrati kako se ove podatke vezano za još više podataka – specifikacija za ovaj dio mogu se naći po poprijeko hipervezu. Svaki dokument odgovor omogućava klijentu da drill down dobiti detaljnije informacije.

Podnijeti PO

Web uslugu stavlja na raspolaganje URL dostaviti PO. Klijent stvara primjer dokument PO koji je u skladu sa PO shemu da su dijelovi Depot je dizajnirao (a objavljen je u WSDL dokument). Klijent podnosi PO.xml kao nosivosti od HTTP POST-a.

Tužilaštvo usluga odgovara na HTTP POST s URL dostavljenim PO. Dakle, klijent može dohvatiti PO bilo koje vrijeme nakon toga (za ažuriranje / edit to).

Tužilaštvo je postala jedna informacija koja se dijeli između klijenta i servera. Dijeljene podatke (PO) dat adresu (URL) od strane servera i izložena kao Web servisa.

Logično URL-ova u odnosu na fizičku URL-ove

A izvor je konceptualni entitet. A reprezentacija je konkretna manifestacija resursa. Ovaj URL:

http://www.parts-depot.com/parts/00345

je logičan URL, a ne fizički URL. Dakle, postoji ne mora biti, na primjer, statičkog HTML stranica za svaki dio. U stvari, ako je bilo milion dijelova onda milion statički HTML stranica ne bi bio vrlo atraktivan dizajn.

[Detalj Implementacija: Dijelovi Depot mogao implementirati uslugu koja dobije detaljne podatke o određenom dijelom zapošljavaju Java Servlet koji raščlanjuje niz nakon ime hosta, koristi broj dijela za upit baze podataka dijelova, formulirati rezultate upita kao XML, i zatim se vratiti XML kao nosivosti od odgovora HTTP-a.]

Kao stvar stila URL-ova ne bi trebalo da otkrije tehniku ​​realizacije koristi. Morate biti slobodan da promenite implementaciju bez uticaja na klijente ili su u zabludu URL-ova.

REST web servisovi karakteristike

Ovdje su karakteristike REST:

  • Klijent-Server: pull-based stil interakcije: konzumiranje komponente povući reprezentacije.
  • Bez državljanstva: svaki zahtjev od klijenta do servera mora da sadrži sve informacije potrebne za razumijevanje zahtjeva, i ne mogu iskoristiti bilo koje čuvaju konteksta na serveru.
  • Cache: poboljšanje odgovora mrežu efikasnost mora biti u stanju da se označeni kao cacheable ili ne-cacheable.
  • Uniformi sučelje: svi resursi se pristupa sa generičkim sučelje (npr HTTP GET, POST, PUT, brisanje).
  • Nazvan resursi – sistem se sastoji od resursa koji su nazvani pomoću URL-a.
  • Međusobno reprezentacije resurs – reprezentacije resursa su međusobno povezani pomoću URL-ova, čime se omogućava klijentu da napreduje iz jedne države u drugu.
  • Slojeviti komponente – posrednika, kao što su proxy servera, cache serveri, gateway, itd, može biti ubačen između klijenata i resurse za podršku performanse, sigurnost, itd

Principi REST dizajna web servisa

  1. Ključ za stvaranje Web Services u REST mreže (i.e., Web) je identifikacija svih konceptualnih entiteta koji želite da razotkrije kao usluga. Iznad smo vidjeli neke primjere resursa: popis dijelova, detaljni podaci dijelu, narudžbenice.
  2. Kreiraj URL svaki resurs. Sredstva treba biti imenice, a ne glagola. Na primjer, ne koristite ovo:
http://www.parts-depot.com/parts/getPart?id=00345

Napomena glagol, getPart. Umjesto toga, koristite imenica:

http://www.parts-depot.com/parts/00345

3. Kategorizacija svoje resurse prema tome da li klijenti mogu samo dobiti prikaz resursa, odnosno da li klijenti mogu mijenjati (dodati) resursa. Za bivšu, da ta sredstva dostupna pomoću HTTP GET. Za kasnije, da ta sredstva dostupna preko HTTP POST, PUT, i / ili DELETE.
4. Svi resursi dostupni putem HTTP GET bi trebao biti nuspojava besplatno. To jest, resursima treba samo vratiti prikaz resursa. Pozivajući se na izvor ne bi trebalo da dovede do modifikaciju resursa.
5. Nijedan čovjek / žena je ostrvo. Isto tako, ne zastupa treba da bude otok. Drugim riječima, stavio hiperveze unutar reprezentacije resursa kako bi se omogućilo korisnicima da bušiti za više informacija, i / ili da dobiju relevantne informacije.
6. Dizajn otkriti podatke postepeno. Ne otkrivaju sve što je u dokumentu jedan odgovor. Pružaju hyperlinkovi dobiti više detalja.
7. Odredite format podataka odgovora koristeći shemu (DTD, W3C sheme, RelaxNG ili Schematron). Za one usluge koje zahtijevaju POST ili PUT da je, takođe pružaju shemu odrediti oblik odgovora.
8. Opisati kako vaše usluge su da se poziva koristeći ili WSDL dokument, ili jednostavno HTML dokumenta.

Sažetak

Ovaj članak je opisao REST kao arhitektonski stil. U stvari, to je arhitektonski stil Web. REST opisuje ono što čini web rade dobro. Držeći se načela ostatak će učiniti vaše usluge rade dobro u kontekstu weba.

U budućnosti članku ću pisati o evoluciji Web koristeći principe REST.

Priznanje

Zahvaljujući Robert Leftwich i Philip Eskelin za svoje vrlo korisnim komentarima u stvaranju ovog dokumenta.

Reference

[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm