<texy><strong>3swineherd…</strong>

…

<texy>Nějak mi nezafungovalo vložení linku z Bloggeru. Takže použij link ze záhlaví komentáře.

<texy>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í</a>.
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.

<texy>[8] Jo…ja myslím, že to chápu podobně. Na základě které věty si myslíš opak?

<texy>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ší.

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

<texy>Krome toho ze jsi popsal RPC a ne REST coz je docela rozdil ;-) tak je to bezestavove chovani.

<texy>[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.

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

<texy>[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.