Original: http://www.xfront.com/REST-Web-Services.html
Original by Roger L. Costello
Voi oferi mai întâi o scurtă introducere în REST și apoi voi descrie modul de a construi servicii Web în stilul REST.
Ce este REST?
REST este un termen inventat de Roy Fielding in teza sa de doctorat [1] pentru a descrie un stil de arhitectură a sistemelor în rețea. REST este un acronim pentru Representational State Transfer.
De ce este numit Representational State Transfer?
Web-ul este format din resurse. O resursă este orice element de interes. De exemplu, Boeing Aircraft Corp poate defini o resursă de 747. Clientii pot avea acces la această resursă cu această adresă URL:
http://www.boeing.com/aircraft/747
O reprezentare a resursei este returnata (de exemplu, Boeing747.html). Reprezentarea plasează aplicația clientului într-o stare. Rezultatul clientului parcurgând un hyperlink în Boeing747.html este o altă resursă accesată. Noua reprezentare plasează aplicația clientului într-o alta stare. Astfel, aplicația clientului se schimba (se transfera) stare cu fiecare reprezentare de resursă -> Representational State Transfer!
Aici este explicația sensului de transfer de stare Representational State Transfer:
“Representational State Transfer este destinat să evoce o imagine a modului în care se comportă o aplicație Web bine conceputa: o rețea de pagini web (o masinarie de stare virtuala), în cazul în care utilizatorul progresează printr-o aplicație prin selectarea link-urilor (tranziții de stare), având ca rezultat pagina următoare (care reprezintă următoarea starea a aplicatiei) fiind transferate utilizatorului și prestate pentru utilizarea lor “.
Motivația pentru REST
Motivația pentru REST a fost de a captura caracteristicile Web care a făcut Web-ul de succes. Ulterior, aceste caracteristici sunt folosite pentru a ghida evoluția Web-ului.
REST – un stil arhitectural, nu standard
REST nu este un standard. Nu vei vedea W3C punand o specificație REST. Nu veți vedea IBM sau Microsoft sau Sun vanzand un set de instrumente dezvoltator REST. De ce? Pentru că REST e doar un stil arhitectural. Nu poti suprima acel stil. O poți înțelege doar, și sa-ti proiectezi serviciile de design Web în acel stil. (Similară stilului arhitectural client-server ping monitor soluţie . Nu exista nici un standard client-server.)
În timp ce REST nu este un standard, face standarde de utilizare:
- HTTP
- URL-ul
- XML / HTML / GIF / JPEG / etc (Resource Reprezentanțe)
- text / XML, text / html, imagine / gif, image / jpeg, etc (tipuri MIME)
Sistemul REST Classic
Web-ul este un sistem REST! Multe dintre aceste servicii Web au fost folosite mulți ani – servicii de cumparari carti, servicii de căutare, dicționar online, etc – sunt servicii bazate pe web REST. Din păcate, ați utilizat REST, a-ti construit servicii REST și nici măcar nu a-ti știu.
REST este preocupat de “imaginea de ansamblu” a Web-ului. Ea nu se ocupă de detaliile de implementare (de exemplu, folosind servleturi Java sau CGI pentru a implementa un serviciu Web). Așa că hai să ne uităm la un exemplu de creare a unui serviciu Web din perspectiva REST.
Piese de Depot Web Services
Piese Depot, Inc (companie fictivă) a implementat unele servicii web pentru a permite clienților săi să:
- obține o listă de piese
- obține informații detaliate cu privire la o anumită parte
- să prezinte o comandă de aprovizionare (PO)
Hai să luam în considerare modul în care fiecare dintre aceste servicii sunt puse în aplicare într-un mod REST.
Listă de piese pentru obtinere
Serviciul web pune la dispoziție o adresă URL către o resursăcu o lista de piese. De exemplu, un client ar folosi această adresă URL pentru a obține lista de piese:
http://www.parts-depot.com/parts
Rețineți că “modul în care” serviciul web generează lista de piese este complet transparenta pentru client. Toti clientii stiu că, dacă el / ea susține URL-ul de mai sus, un document care conține lista de piese este returnat. Având în vedere că punerea în aplicare este transparenta clienților, Parts Depot este liber să modifice punerea în aplicare care stau la baza acestei resurse, fără a afecta clienții. Acesta este cuplajul slab.
Iată documentul pe care-l primește clientul:
<?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>
[Să presupunem că, prin negocierea conținutului serviciului stabilit că clientul dorește reprezentarea ca XML (pentru mecanism-la-mecanism de prelucrare).] Rețineți că lista de piese are legături pentru a obține mai multe informații detaliate despre fiecare parte. Aceasta este o caracteristică esențială REST. Transferurile clientului de la o stare la alta, prin examinare și alegând dintre URL-urile alternative din documentul de răspuns.
Obtine partea de date detaliata
Serviciul web pune la dispoziție o adresă URL pentru fiecare resursă in parte. De exemplu, iată cum un client cere partea 00345:
http://www.parts-depot.com/parts/00345
Iată documentul pe care-l primește clientul:
<?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>
Observă din nou modul în care aceste date sunt legate în continuare de mai multe date – specificația pentru această parte poate fi găsită verificand hyperlink-ul. Fiecare document de răspuns permite clientului sa examineze pentru a obține informații mai detaliate.
Depunere PO
Serviciul web pune la dispoziție o adresă URL pentru a depune PO. Clientul creează un document dovada de PO, care este în conformitate cu schema PO pe care Parts Depot a proiectat-o (și publicat într-un document WSDL). Clientul sustine PO.xml ca sarcină utilă a unui HTTP POST.
Serviciul de PO răspunde la HTTP POST cu o adresă URL către PO depusă. Astfel, clientul poate prelua PO in orice moment ulterior (pentru a actualiza / edita). PO a devenit o informație care este împărțită între client și server. Informațiilor distribuite (PO) este data o adresă (URL) de către server și este expusa ca un serviciu Web.
URL-uri logice versus URL-uri fizice
O resursă este o entitate conceptuală. O reprezentare este o manifestare concretă a resursei. Această adresă URL:
http://www.parts-depot.com/parts/00345
Este o adresă URL logică, nu o adresă URL fizică. Astfel, nu este necesar să fie, de exemplu, o pagină HTML statica pentru fiecare parte. De fapt, dacă ar exista un milion de părți, apoi un milion de pagini HTML statice nu ar fi un design foarte atractiv.
[Detalii de implementare: Parts Depot ar putea implementa serviciul care primește date detaliate cu privire la o anumită parte prin angajarea unui servlet Java care analizează șirul după numele de gazdă, folosește piesa pentru a interoga partea de baza de date, să formuleze rezultatele de interogare XML și apoi returnează XML ca sarcină utilă a răspunsului HTTP.]
Ca o chestiune stil URL-uri nu ar trebui să dezvăluie tehnica de implementare utilizată. Trebuie să fii liber să schimbi implementarea fără a afecta clienții sau sa ai URL-uri înșelătoare.
Caracteristici REST Web Services
Aici sunt caracteristicile REST:
- Client-Server: un stil de interacțiune bazat pe tragere: componente cu consum trage reprezentări.
- Apatrid: fiecare cerere de la client la server trebuie să conțină toate informațiile necesare pentru a înțelege cererea, și nu pot să profite de orice context stocat pe server.
- Cache: pentru a îmbunătăți eficiența rețelei de răspunsuri trebuie să poată fi etichetate ca cacheable sau non-cacheable.
- Interfață uniformă: toate resursele sunt accesate cu o interfață generică (de exemplu, HTTP GET, POST, PUT, DELETE).
- Resurse mentionate- sistemul este format din resurse care sunt numite cu ajutorul unui adresă URL.
- Reprezentări de resurse interconectate- reprezentările resurselor sunt interconectate folosind URL-uri, permițând astfel unui client să progreseze de la o stare la alta.
- Componente din strat- intermediari, cum ar fi servere proxy, servere cache, gateway-uri, etc, pot fi inserate între clienți și resurse pentru a sprijini performanta, securitatea, etc.
Principiile REST Web Design Service
- Cheia pentru a crea Web Services într-o rețea REST (adică, Web-ul) este acela de a identifica toate entitățile conceptuale pe care doriți să le expuneti ca servicii. Mai sus am văzut câteva exemple de resurse: lista pieselor,parte de date detaliata ,cumparare comanda.
- Creați o adresă URL pentru fiecare resursă. Resursele ar trebui să fie, nu substantive ci verbe. De exemplu, nu utilizați acest lucru:
http://www.parts-depot.com/parts/getPart?id=00345
Notați verbul, getPart. În schimb, utilizați un substantiv:
http://www.parts-depot.com/parts/00345
- Categorisiți resursele în funcție dacă clienții pot primi doar o reprezentare a resursei, sau dacă clienții pot modifica (adauga la) resursa. Pentru prima, faceti acele resurse accesibile cu ajutorul unui HTTP GET. Pentru mai târziu, faceti acele resurse accesibile prin HTTP POST, PUT, și / sau DELETE.
- Toate resursele accesibile prin HTTP GET trebuie sa fie fara efecte secundare. Aceasta este, resursa ar trebui să se întoarcă la doar o reprezentare a resursei. Invocînd resursa nu ar trebui să conducă la modificarea resursei.
- Nici un bărbat / femeie este izolata. De asemenea, nici o reprezentare nu ar trebui să fie izolata. Cu alte cuvinte, pune hyperlink-uri în cadrul reprezentanțelor de resurse pentru a permite clienților accesarea a mai multor informații, și / sau pentru a obține informații asociate.
- Proiectati pentru a dezvălui date treptat. Nu dezvălui totul într-un document unic de răspuns. Furnizeaza hyperlink-uri pentru a obține mai multe detalii.
- Se specifică formatul datelor de răspuns folosind o schemă (DTD, W3C Schema, RelaxNG sau Schematron). Pentru acele servicii care necesită un POST sau PUT la acesta, oferă, de asemenea o schemă pentru a specifica formatul răspunsului.
- Descrieți modul în care sunt invocate serviciile tale, folosind fie un document WSDL, sau pur și simplu un document HTML.
Rezumat
Acest articol este descris ca REST fiind un stil arhitectural. De fapt, este stilul arhitectural al Web-ului. REST descrie ceea ce face ca Web-ul sa funcționeze bine. Aderând la principiile REST vor face serviciile dvs. sa funcționeze bine în contextul Web-ului.
Intr-un articol viitor, voi scrie despre evoluția Web-ului folosind principiile REST.
Recunostinta
Grație lui Robert Leftwich si Philip Eskelin pentru comentariile lor foarte utile în crearea acestui document.
