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

Roger L. Costello

Először röviden bemutatom a REST-et, majd leírom, hogyan építhetek webszolgáltatásokat a REST stílusban.

Mi a REST?

A REST egy olyan kifejezés, amelyet Roy Fielding írt Ph.D. Disszertáció [1] a hálózati rendszerek architektúrájának leírására. A REST a reprezentatív állami átutalásnak megfelelő rövidítés.

Miért nevezik reprezentációs állami átruházásnak?

A web forrásokból áll. Az erőforrás minden érdekes elem. Például a Boeing Aircraft Corp egy 747-es erőforrást határozhat meg. Az ügyfelek hozzáférhetnek ehhez az erőforráshoz az URL-címmel:

Az reprezentáció ábrázolása visszaadódik (például Boeing747.html). A reprezentáció az ügyfélalkalmazást egy állapotba helyezi. Az ügyfélnek a Boeing747.html hiperhivatkozáson átmenő eredménye egy másik erőforrás. Az új megjelenítés az ügyfélalkalmazást egy másik állapotba helyezi. Így az ügyfélalkalmazás az erőforrás-reprezentációval (átviteli) állapotot vált ki -> Reprezentációs Állami Transzfer!

Itt van Roy Fielding magyarázata a reprezentatív állami átadás jelentésének:

“A reprezentációs állami átvitel célja, hogy felidézzen egy képet arról, hogy a jól megtervezett webalkalmazás viselkedik-e: olyan weboldalak hálózata, ahol a felhasználó egy alkalmazáson keresztül halad előre a linkek kiválasztásával (állapotátlépések), így a következő oldal (a következő állapotot Az alkalmazásnak), amelyet a felhasználónak továbbítanak és felhasználásukra átadnak.”

Motiváció a REST számára

A REST motivációja az volt, hogy megragadja a web jellemzőit, amelyek sikeresek voltak a weben. Ezt követően ezeket a tulajdonságokat használják a web evolúciójának irányítására.

REST – építészeti stílus, nem szabvány

A REST nem szabvány. Nem fogod látni, hogy a W3C egy REST specifikációt mutatott be. Az IBM vagy a Microsoft vagy a Sun nem fogja látni a REST fejlesztői eszközkészletét. Miért? Mivel a REST csak építészeti stílus. Nem lehet palackozni ezt a stílust. Csak meg tudja érteni, és tervezheti webszolgáltatásait ebben a stílusban. (Az ügyfél-kiszolgáló építészeti stílusához hasonlóan nincs ügyfél-kiszolgálói szabvány.)

Bár a REST nem szabvány, szabványokat alkalmaz:

• HTTP
• URL
• XML/HTML/GIF/JPEG/etc (erőforrás képviseletek)
• text/xml, text/html, image/gif, image/jpeg, etc (MIME típusok)

A klasszikus REST rendszer

A web egy REST rendszer! Számos ilyen webes szolgáltatás, amelyet sok éve használ – a könyvrendelés, a keresési szolgáltatások, az online szótár szolgáltatásai stb. – a REST alapú webszolgáltatások. Sajnos, a REST-et használtad, REST szolgáltatásokat építettél, és még csak nem is tudtad.
A REST az internet nagyszerű képét érinti. Nem foglalkozik a végrehajtás részleteivel (például a Java servletek vagy a CGI használatával webszolgáltatás megvalósításához). Vessünk egy példát egy webszolgáltatás létrehozására a REST “nagy kép” szempontból.

Parts Depot Webszolgáltatások

A Parts Depot, Inc (fiktív vállalat) olyan webszolgáltatásokat alkalmazott, amelyek lehetővé teszik ügyfeleinek, hogy:

• kap egy listát az alkatrészekről
• részletes információt kaphat egy adott részről
• vásárlási rendeletet (PO)

Vegyük fontolóra, hogyan hajtják végre ezeket a szolgáltatásokat minden bizonnyal.

Szerezd meg az alkatrészek listáját

A webszolgáltatás elérhetővé teszi az alkatrészlista erőforrás URL-jét. Például egy ügyfél ezt az URL-t használja az alkatrészlista beszerzéséhez:

Ne feledje, hogy a “hogyan” a webszolgáltatás generálja az alkatrészlista teljesen átlátható az ügyfél számára. Minden ügyfél tudja, hogy ha elküldi a fenti URL-t, akkor az alkatrészlistát tartalmazó dokumentumot visszaadják. Mivel a bevezetés átlátható az ügyfelek számára, az Parts Depot szabadon módosíthatja ennek az erőforrásnak az alapul szolgáló megvalósítását, anélkül, hogy befolyásolná az ügyfeleket. Ez laza csatlakozás.

Itt található az ügyfél által megkapott dokumentum:

[Tegyük fel, hogy a tartalom-tárgyaláson keresztül a szolgáltatás meghatározta, hogy az ügyfél XML formátumban kívánja megjeleníteni (gépi gépre történő feldolgozáshoz). Megjegyzendő, hogy az alkatrészlista hivatkozásokkal rendelkezik, amelyek részletesen információkat tartalmaznak az egyes részekről. Ez a REST legfontosabb jellemzője. Az ügyfél az egyik államról a másikra átmásolja a válaszadag alternatív URL-jeinek vizsgálatából és kiválasztásából.

Részletes részadatok beszerzése

A webszolgáltatás elérhetővé teszi az egyes részforrások URL-címét. Például, itt egy ügyfél kéri a 00345 részt:

Itt található az ügyfél által megkapott dokumentum:

Ismételje meg, hogy ezek az adatok még több adathoz kapcsolódnak – ennek a résznek a specifikációja megtalálható a hiperlink átkerülésével. Mindegyik válaszdokumentum lehetővé teszi az ügyfelek számára, hogy részletesebb információkat kapjanak.

Beszerzési megbízás benyújtása

A webszolgáltatás elérhetővé teszi a megrendelés benyújtására szolgáló URL-t. Az ügyfél olyan rendelés példánydokumentumot hoz létre, amely megfelel a rendelés sémanak, amelyet az Parts Depot tervezett (és WSDL dokumentumban publikált). Az ügyfél a PO.xml-ot HTTP POST terhelésként küldi el.
A Vásárlási megbízás szolgáltatás a HTTP POST-ot a benyújtott Megrendelés URL-jével válaszolja meg. Így az ügyfél bármikor lekérheti a Megrendelést (frissíteni/szerkeszteni). A rendelés egy olyan információ, amely az ügyfél és a szerver között oszlik meg. A megosztott információk (Vásárlási megbízás) a kiszolgáló címét (URL-címét) adják meg, és webszolgáltatásként jelenik meg.

Logikai URL-ek a fizikai URL-ekhez képest

Az erőforrás fogalmi egység. Az ábrázolás az erőforrás konkrét megnyilvánulása. Ez az URL:

Logikai URL, nem pedig fizikai URL. Így nem kell minden egyes részhez statikus HTML-oldalnak lennie. Valójában, ha lenne egy millió rész, akkor egy millió statikus HTML oldal nem lenne nagyon vonzó design.

[A megvalósítás részletezése: A Depot részei végrehajthatták azt a szolgáltatást, amely részletes adatokat gyűjt egy adott részről egy Java Servlet alkalmazásával, amely a gazdagép után elemzi a karakterláncot, a részszámot használja a részadatok lekérdezéséhez, a lekérdezési eredményeket XML formátumban, és Majd küldje vissza az XML-t a HTTP-válasz hasznos terheléséért.]
A stílusos URL-ek esetében nem szabad feltárni az alkalmazott végrehajtási technikát. Szabadon kell változtatnia a végrehajtását anélkül, hogy az ügyfeleket befolyásolná vagy félrevezető URL-címeket tartalmazna.

REST webszolgáltatások jellemzői

Itt vannak a REST jellemzői:

• Ügyfél-kiszolgáló: pull-alapú interakciós stílus: az összetevők felhúzása.
• Hontalan: az ügyféltől a kiszolgálóig minden kérelemnek tartalmaznia kell a kérelem megértéséhez szükséges összes információt, és nem tudja kihasználni a tárolt környezetet a kiszolgálón.
• Gyorsítótár: a hálózati hatékonysági válaszok javítása érdekében képesnek kell lennie címkézésre gyorsító vagy nem gyorsítótárként.
• Egységes felület: minden erőforrás elérhető egy általános interfésszel (például HTTP GET, POST, PUT, DELETE).
• Nevesített erőforrások – a rendszer erőforrásokat tartalmaz, amelyeket egy URL használatával neveznek el.
• Összekapcsolt erőforrás-ábrázolások – az erőforrások ábrázolása URL-címekkel összekapcsolódik, ezáltal lehetővé teszi az ügyfél számára, hogy egyik államról a másikra haladjon.
• Réteges összetevők – közvetítők, például proxykiszolgálók, gyorsítótár-kiszolgálók, átjárók stb. Beilleszthetők az ügyfelek és az erőforrások között a teljesítmény, a biztonság stb.

A REST webszolgáltatástervének alapelvei

1. A REST hálózatban (vagyis a weben) létrehozott webszolgáltatások létrehozásának kulcsa az összes azon fogalmi egység azonosítása, amelyet szolgáltatásként kíván megjeleníteni. Fentebb láttunk néhány példát az erőforrásokról: alkatrészlista, részletes részadatok, vételi megbízás.

2. Hozzon létre egy URL-t minden erőforráshoz. Az erőforrásoknak főneveknek, nem igéknek kell lenniük. Ne használja ezt például:

http://www.parts-depot.com/parts/getPart?id=00345

Jegyezd meg az igét, getPart. Ehelyett használjon egy főnevet:

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

3. Sorolja fel az erőforrásokat, attól függően, hogy az ügyfelek csak megkapják-e az erőforrás ábrázolását, illetve hogy az ügyfelek módosíthatják-e az erőforrást. Az előbbiekhez érdemes elérni ezeket az erőforrásokat egy HTTP GET használatával. A későbbiekben ezeket az erőforrásokat elérhetővé teheti a HTTP POST, PUT és/vagy DELETE használatával.

4. A HTTP GET-n keresztül elérhető valamennyi forrásnak mellékhatásmentesnek kell lennie. Ez azt jelenti, hogy az erőforrásnak csak az erőforrás ábrázolását kell visszaadnia. Az erőforrás meghívása nem eredményezheti az erőforrás módosítását.

5. A férfi/nő nem egy sziget. Hasonlóképpen, egyetlen képviselet sem lehet sziget. Más szóval, helyezzen hyperlinkeket az erőforrás-megjelenítéseken belül, hogy az ügyfelek további információkat szerezhessenek, és/vagy hozzájuthassanak a kapcsolódó információkhoz.

6. Tervezés az adatok fokozatos megjelenítésére. Ne mutasson mindent egy válasz-dokumentumban. Adjon meg hiperlinket további részletekért.

7. Adja meg a válaszadatok formátumát egy sémával (DTD, W3C Schema, RelaxNG vagy Schematron). Azoknál a szolgáltatásoknál, amelyekhez POST vagy PUT tartozik hozzá, szintén tartalmaz egy sémát, amely meghatározza a válasz formátumát.

8. Mutassa be, hogyan kell a szolgáltatásokat WSDL dokumentum vagy csak HTML dokumentum segítségével használni.

Összefoglaló

Ez a cikk a REST-et építészeti stílusként írta le. Valójában ez a web építészeti stílusa. A REST leírja, mi teszi a weben jól működik. A REST elvekhez való ragaszkodás a webszolgáltatások keretében jól működik.
Egy jövőbeni cikkben a webes változatról a REST alapelvek alapján fogok írni.

Elismerés

Köszönet Robert Leftwichnak és Philip Eskelinnek a nagyon hasznos megjegyzésekért a dokumentum megalkotásában.

Referenciák

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