Jak jsem (ne)pochopil REST

28. February 2008

S křížkem po funusu ale přece! V tomto článku bych chtěl několika větami okomentovat :lednovou přednášku":http://www.java.cz/detail.do?… Jakuba Podlešáka Java API pro RESTful web services. Po obyčejném blogování se mi už pekelně stýskalo. Od půlky prosince totiž nedělám nic jiného než že se snažím přivést k životu naše kontaktní čočky.

REST

REST chápu jako soubor pravidel pro manipulaci s daty po síti (zpravidla pomocí HTTP protokolu). V RESTu se pracuje se resourci – zdroji. Každý zdroj má svoji unikátní adresu. Pomocí volání adresy zdroje s ním lze provádět operace. Od prostého načtení po vytvoření, modifikaci až po smazání. Kromě zavolání zdroje pomocí adresy (URL) lze do těla požadavku zabalit další data – například pro vytvoření nového zdroje. Data mohou být v různé formě – např XML, JSON, plain text…

REST naopak nedefinuje autentizaci a autorizaci uživatelů. REST je bezstavový.

Jak je to s tou stavovostí RESTu?

A právě o stavovosti RESTu bych se chtěl zamyslet. Na přednášce proběhla vášnivá debata na téma stavovost RESTu. Padly zde názory, že když pracuju s webovou aplikací používající REST a uložím nový zdroj, tak se přece musí jednat o stavové chování. Vždyť se přece změnil stav aplikace.

Výše uvedený názor je nesmysl. Se stavovostí RESTu je to stejně jako se stavostí HTTP protokolu – je nestavový. Uvedu na jednoduchém příkladu. Tím příkladem jsou sessions.

Příklad se sessions

Sessions fungují tak, že server přibalí do odpovědi klienta unikátní idenfikátor, který označuje session id. Toto cookies se pak přenáší při další komunikaci mezi serverem a klientem. Klient session id přibaluje buď do:

URL
POST dat
cookies

A naprosto stejně to funguje i s RESTem. Když budeme mít resource na adrese http://vavru.cz/eshop/vytvorit-kosik/, může odpověď vypada například takto – http://vavru.cz/eshop/kosik/wsdei9012309a/. Dostali jsme zpět adresu na nově vytvořený košík. Když pak klient chce s tím to košíkem (každý klient má svůj košík) musí uvést celou adresu košíku. Takže pro přidání nové položky bychom mohli použít například takovýhle odkaz – http://vavru.cz/eshop/kosik/wsdei9012309a/pridat-produkt/ a v těle požadavku specifikovat o jaký produkt se jedná a například počet kusů.

Zdá se vám to jednoduché?

Mně taky. Proto nechápu tolik případů nepochopení ze strany posluchačů. Možná jsem to celé jenom špatně pochopil a chyba je na mé straně. V tom případě prosím nějakého zkušeného RESTovače, aby mě například pomocí komentáře přivedl na správnou cestu.

Článek patří do kategorie: Java

Sledovat @vavru

12 Komentářů Přidat komentář

1. David Grudl | 29. February 2008 v 13.39

S tím nesouhlasím.

Jako kritérium „stavovosti“ bych vzal to, že stav je uložen na straně serveru (tedy serializovaný v session souboru). Kdyby se ten serializovaný stav přenášel v URL/POST/cookies, teprve pak by skutečně o bezestavový mechanismus. Pak by stejný dotaz generoval (zjednodušeně) stejnou odpověď. Nezáleželo by na předchozí historii.

Jak na historii záleží, jde o stavový mechanismus.
2. Lukas | 29. February 2008 v 14.04

Ono take zalezi na urovni abstrakce
Viz napr.: TCP vs UDP.

Snad nechcete rict, ze JSF kdyz uklada stav session do stranky, tak je to z pohledu programatora bezstavove?
3. Vlasta | 29. February 2008 v 14.20

[1] Pomocí restu můžu vytvořit objekt a v odpovědi dostanu odkaz na objekt. Z mého pohledu je to stejné jako práce se session (v určitých aspektech). Session se taky vytvoří pro každého uživatele unikátních (stejně jako kdybych si vytvářel ekvivalentní persistentní objekt pomocí RESTu). V RESTu pak musím specifikovat unikátní adresu tohoto zdroje pro přístup k němu. Připadá mi to jako ekvivalent k HTTP…kdy mi unikátní zdroj tvoří URL společně s hodnotou session id.

[2] Opravdu je otázka co myslíme tou stavovostí. Faktem zůstává, že mluvit o stavovosti je ve finále trošičku zcestné…protože i u nestavových řešení (REST) si lze nají způsoby, jak ony „stavové“ requirementy řešit.
4. Dagi | 1. March 2008 v 12.42

Bezestavove je to ve chvili, kdy ten nakupni kosik bude jako resource a zaroven (to uz nerikas) se bude ten kosik resp. jeho reprezentace posilat tam a zpet s kazdym pozadavkem. Takze pridani zbozi do kosiku bude GET reprezentace kosiku, zmena jeho reprezentace (pridame polozku) a POST reprezentace kosiku.

Podle me na te prednasce nebylo uplne nejlepe vysvetleno, ze je rozdil mezi stavem aplikace a komunikace. To o co bezi je, stav komunikace mezi klientem a serverem. V RESTu je komunikace vzdy bezestavova, kdezto v pripade session je komunikace vzdy stavova (session je ten stav). Pokud to prevedu zpet na ten nakupni kosik, tak na tom je to krasne videt. Nakupni kosik je stavem komunikace ve chvili kdy bude lezet v session. Ve chvili kdy z nej udelas resource, stane se stavem aplikace a komunikace jako takova bude moci byti bezestavova.
5. Vlasta | 1. March 2008 v 14.13

[4]Zapomeňme na košík a mějte například knihovnu, která bude umožňovat vkládat nové knihy. Zavoláním URL /knihovna/pridat/ a specifikováním dat o nové knize v požadavku se založí nová kniha a v odpovědi bude vrácena adresa nově vytvořeného zdroje – například /knihovna/kniha/12345/. Tak…a teď budu chtít u knihy nastavit autory. Zavoláním /knihovna/kniha/12345/pridatautora/ a specifikováním dat v těle požadavku přidám autora a dostanu v odpovědi jeho adresu.

Tohle so jsem popsal je podle mého nestavové chování. Pokud tedy tou stavovostí není myšleno to, že je systém schopen vytvářet a modifikovat data.
6. Dagi | 2. March 2008 v 9.44

Krome toho ze jsi popsal RPC a ne REST coz je docela rozdil tak je to bezestavove chovani.
7. lzap | 3. March 2008 v 10.49

Záleží na úhlu pohledu, zřejmě protokol jako takový skutečně stavový není, ale na REST by se mělo spíše pohlížet jako na architekturální záležitost.
8. tapik | 23. April 2008 v 10.42

No, nejsem si jist, zda jsi princip RESTu pochopil. Bezestavovost RESTu je v tom, že komunikace neodráží jinak stav klienta, pokud nepočítám algoritmus jeho práce zachytitelný jako posloupnost RESTových operací nad různými stavovými zdroji.
Pokud bude provedena logicky stejná operace nad daným zdrojem (nebo i zdroji, záleží na aplikaci a jejím protokolu, třeba BIND(URI1,URI2) může změnit stav OBOU zdrojů současně), musí dojít k logicky stejnému výsledku. Pokud je operace přidej knihu do košíku, tak jsou-li kniha i košík stále dostupné zdroje a operace je povolena (košík je stavový, může mít stav nepřijímám nic dalšího), měla by v košíku přibýt položka kniha. A je irelevantní, jestli tam už kniha byla nebo nikoli. U operací typu získej stav (HTTP GET) je to ještě čitelnější.
9. Vlasta | 23. April 2008 v 11.02

[8] Jo…ja myslím, že to chápu podobně. Na základě které věty si myslíš opak?
10. tapik | 23. April 2008 v 12.10

No, jak bych to, z textu neplyne, co si myslíš o RESTovosti HTTP session. Sice jsi ji uvedl jako příklad, ale nemyslím, že by to byl příklad správný. HttpSession může byt sama o sobe RESTózním zdrojem (URL rewrite) ale také nemusí (cookies, hidden input field v datech etc.). Záleží na tom, jak k ní přistupuješ a jak je zakomponována do celé aplikace. Jukni na <a>Tapikování: Krátké oRESTování.
Jinak HTTP je RESTové do té míry, do jaké míry je použito. POST může zavést a zavádí drsnou NERESTovost, například díky oněm HTML hidden input fieldům, které jsou tu právě proto, abychom měli udržený stav klienta v datech komunikace a to je antiRESTovina jak kráva.
11. tapik | 23. April 2008 v 12.26

Nějak mi nezafungovalo vložení linku z Bloggeru. Takže použij link ze záhlaví komentáře.
12. 2cronies&hellip | 12. January 2022 v 23.02

3swineherd…

…