Kdy parametrizovaný GET a kdy dvě operace GET a QUERY?

Na můj předchozí blogpost ze série oRESTování reagoval Petr Ferschmann, člen týmu WinStromu. Kromě poděkování za pochvalu ale také píše:

Osobně považuji za ekvivalentní tyto formy zápisu:
/faktura-vydana/(stavUhrK='uhrazeno%27)
/faktura-vydana/?filter=stavUhrK=%3d%27uhrazeno%27

Jak jistě tušíte, nemohu s tímto souhlasit, a proto vznikl tento článeček.

Věc, která vypadá z pohledu HTTP eqivalentně, z pohledu Java kódu eqivalentně, dokonce i z pohledu uživatele, z pohledu RESTu eqivalentní není. Webovému prohlížeči je jedno, které URL uživatel napíše, je to jenom směs znamének. Jestli je na serveru logika udělaná tak, že v metodě doGet() HttpServletu vezmete z request.getRequestPath() jednu část a prohlásíte ji za vyhledávací řetězec (filtr) nebo tutéž část získáte pomocí request.getParameter("filter"), je také celkem buřt. Pro HTTP protokol je to jedno, protože první řádek bude pokaždé vypadat stejně, tedy buď

GET /faktura-vydana/(stavUhrK='uhrazeno%27) HTTP/1.1

nebo

GET /faktura-vydana/?filter=stavUhrK=%3d%27uhrazeno%27 HTTP/1.1

Jak je to ale z pohledu RESTu? Začněměž tím, že si řekneme kousek základní definice RESTu - je to množina N operací, kde N je dostatečně malé číslo, společným pro všechny objekty systému (kterým říkáme zdroje neboli resources). Každý zdroj je unikátně identifikovatelný pomocí URI, za které se považuje buď URL nebo URN.

Tolik základní definice. Teď něco k operacím. Smysl mít několik málo jednotných operací je fakt, že se klient nemusí příliš zajímat o jaký zdroj se jedná a jaké má rozhraní, prostě s ním provede operaci, kterou požaduje, a ta buď půjde nebo nepůjde nebo udělá něco jiného než na jiném zdroji atd. Vzhledem k tomu, že operace se provádějí na zdrojích, které jsou URIčkované, můžeme prohlásit, že parametrem každé obecné operace je URI zdroje.

Těch parametrů ale může být povícero, a to hned ve dvou směrech. Uvedu dva příklady:

RESTová implementace Facebookového "Sdílet" by měla čtyři parametry: URI mojí zdi (tedy URI kolekce, kde se má zdroj (nový záznam o sdílení) vytvořit), URI toho, co chci sdílet, URI autora (ano, URI, Facebook mne musí UNIKÁTNĚ identifikovat!!!), a komentář.

Druhým příkladem budiž operace GET z WinStromu. GET na URL s jedním záznamem má parametr Accept, který definuje formát záznamu, který klient požaduje (XML,PDF,...).

Když jsme si toto řekli, vraťme se k WinStromu a jeho filtru. Každé URI reprezentuje zdroj. Jiný zdroj! Pakliže budeme chápat operaci GET klasicky, tedy "vrať obsah", tak GET na /faktura-vydana/ vrátí obsah kolekce faktura-vydaná, kdežto GET na /faktura-vydana/(stavUhrK='uhrazeno%27) vrací obsah - ČEHO? Z logiky věci zdroje reprezentujícího všechny zdroje z kolekce "faktura-vydana", které mají stav UhrK "uhrazeno%27". Jenomže - co můžeme říct o tom zdroji? Jedná se o zdroj nezávislý? Můžeme ho čapnout a přenést jinam? Jak se vlastně vytváří? Jaké jsou na něm nadefinovány jiné operace než GET? Není to vlastně jenom takový "virtuální" zdroj?

Musím se přiznat, že při slovním spojení "Virtuální RESTový zdroj" zamrazí v zádech. Zkusme se na to podívat z jiné stránky věci. To, co chceme, není IMHO až tak nový zdroj, jako spíše JINÝ POHLED kolekci "faktura-vydana", tedy na zdroj /faktura-vydana/ . Takový pohled, který bude obsahovat pouze takové zdroje, které odpovídají podmínce 'mají stav UhrK "uhrazeno%27" '. Tento pohled pak z hlediska RESTu můžeme udělat na třech místech: na straně klienta, poskytovatele zdroje či interceptorem. Protože chceme dát klientovi maximální komfort a navíc minimalizovat tok dat, předpokládejme, že tento nový pohled budeme budovat na straně poskytovatele zdroje, tedy na serveru.

Jak toho docílit? Velice jednoduše. Rozšíříme operaci GET o nepovinný parametr Filtr (nebo povinný s existující konstantou reprezentující nefiltrování). Na serveru se pak rozhodneme, zda máme či nemáme filtrovat a jak se k tomu dostaneme. Nemáme tak žádný další, tfuj, "virtuální zdroj", tfuj. A jak to v praxi provedeme? Jak to dělá HTTP - k operaci GET na kolekci přidáme parametr filter.

Pojďme ale ještě dál. Onen pohled reprezentovaný parametrem Filtr mění poměrně významně obsah, který klient dostane. Nejde tedy o čistý "jiný pohled na data". Ihned po interní operaci GET se na výsledek provede operace FILTR (a jestli je to uděláno v Javě, v XSLT/XPath či SQL, je celkem buřt). Můžeme tedy tuto dvojoperaci považovat za jednu - FILTEREDGET. GET pak nemá parametr Filtr, tento parametr je parametrem nové operace.

Zeptáte se - no jo, ale když HTTP operaci FILTEREDGET nemá, tak co s tím? Ale to je přece jednoduché, milý Watsone! Tak jak RESTová operace GET není HTTP GET, pouze se na ni mapuje, pak si řekněmež, že si operaci FILTEREDGET namapujeme tak, že URL HTTP GETové operace na kolekci rozšíříme o parametr filter ... :-D

Že je to stejné jako v případě parametru? Ale jděte. Pouze převod do HTTP je stejný. Na straně serveru vám to napoví, že tuto cestu je dobré řešit jinou interní operací. Při vytvoření RESTové (nebo i SOAPové) WebServisy to budete zveřejňovat jako jinou operaci.

Zkusím to teď ještě zobecnit:

Základní otázka Života, vesmíru a vůbec má jasnou odpověď - 42. Nejasná je právě ona otázka.

Otázka, zda cpát či necpát jazyk do URL má také jasnou odpověď - pro všechnu matku přírodu NEE!!!

Jasná otázka, zda použít princip separátních zdrojů, parametrizovanou operaci GET nebo dvě operace GET a FILTEREDGET/QUERY/COKOLI_PODOBNÉHO, jasnou odpověď nemá. Je třeba k tomu přistupovat s mužskou schopností plnohodnotné syntézy či ženskou intuicí:

Rozdílné zdroje použijte tam, kde se opravdu o dva rozdílné zdroje jedná. GET "Aktuální seznam členů CZLUGu", GET "seznam členů CZLUGu počáteční", GET "seznam členů CZLUGu verze 234".

Parametrizujte tam, kde se jedná o jiné formy reprezentace téhož zdroje. GET "Seznam členů CZLUGu"?platny_ke_dni=[puvodni|fcil|YYYY-MM-DD]. Nebo jiný formát záznamu ala WinStrom.

Jinou operaci, pokud se jedná o stejný zdroj dat, ale s až diametrálně odlišným obsahem - typicky vyhledávání. GET "Seznam členů CZLUGu", QUERY "Seznam členů CZLUGu"?query=ti_co_nezaplatili_a_zacinaji_pismenem_fň "

Ufff. Doufám, že to někomu pomůže při rozhodování či pro lepší pochopení principů RESTu.

WinStrom - krásný příklad REST API

Tak jsem se zase rozhodl vrátit se k oRESTování. První příspěvek bude o tom, že i u nás v republice umíme udělat pěkné RESTózní API.
Při shánění materiálů jsem dnes narazil na REST API k účetnímu systému WinStrom. A je opravdu pěkné. Ale má i své mouchy.

Samozřejmě jako transportní protokol použili HTTP. Podporují HTTPS a HttpBasic - což ve spolupráci s přístupovými právy dostatečně zabezpečuje bezpečnost dat. Používají klasické operace GET, POST, PUT a DELETE (PUT a POST zeqivaletnili, což ale samozřejmě není nic proti RESTóznosti API), používají celkem hojně HTTP status.

URL jsou taky HTTP. Celkem logicky nejsou neprůhledná - mají svoji logiku.

Pro práci s kolekcí jedné evidence to jsou:
/ID.firmy/typevidence{/[reports|properties|relations|filtr]}

a pro práci s konkrétní položkou
/ID.firmy/typevidence/ID.záznamu{.formát}{/podevidence} (tady si nejsem jist, jestli ten formát je povinný nebo není, IMHO by být neměl, ale z docky plyne, že je)

Co se týká RESTových operací, tak si vystačí se čtyřmi - klasický CRUD.

CREATE se volá na kolekci. Návratová hodnota je buď neúspěch nebo úspěch. Úspěch v sobě obsahuje identifikátor vytvořeného zdroje.

UPDATE se volá na konkrétní zdroj - tam jdou nová data, zpátky status operace.

DELETE je klasický - jenom jsem nenašel, na co vše se dá volat.

GET je pěkný. Je sice parametrizovaný, ale parametry lze rozdělit do tří kategorií - stránkování a řazení, přidání metadat a (s tím mám kapku problém) XPath na výsledek, jestliže je ve formátu XML (z důvodu omezení přenášených dat)

Až doposud popis a chvála. Teď ale vady na kráse:

• XPath jsem už zmínil, ale to není zas takový problém
• Operace CREATE vrátí identifikátor záznamu, nikoli URL, takže URL si uživatel musí sám poskládat, a to je samozřejmě proti RESTu
• GETové URL obsahuje formát výsledku - zde by bylo na místě použít parametr v QUERY_STRING, ale chápu, že MS Explorer by si s tím nemusel poradit (alespoň v dřevních dobách používal MSIE příponu ke stanovení content-type :-) )
• A na závěr to nejhorší. PARAMETR filtr pro fitrování dat na kolekci není použit jako parametr, nýbrž jako součást identifikátoru, což je VYSOCE nehezké. Cpát přímo do URL ořezanou obdobu SQL (viz syntaxe Filtrování záznamů) mi přijde více než nechutné.

oRESTované dotazy

Nedávno do emailové konference na java.cz přišel dotaz, jak co nejlépe do RESTu nacpat různé filtry.

Zdravim konfereneciu

Zacinam s REST a zakladne principy som snad pochopil (CRUD ->
POST,GET,PUT,DELETE). Ale neviem presne ako realizovat filtrovanie
zaznamov.

Napriklad:
mam zoznam uzivatelov ktory maju polozky: age, firstName, lastName,
atd. Ak chcem nacitat vsetky zaznamy tak dam GET request na adr.
'http://adresa.server/users' vrati mi zoznam vsetkych uzivatelov. Ale ak
by som chcel filtrovat zaznamy podla kriterii napr:
firstName='James' AND lastName!='Bond' OR age>40
Akym sposobom sa dotazovat k tymto zaznamom ? Napadaju ma nasedovne
sposoby:

1) cely dotaz dat do URL:

http://adresa/users/search/v1,s1,c1,o1: ... :vn,sn,cn,o1/orderby/xyz/...

n=1..m
vn - variable, napr: 'firstName'
sn - string, napr: 'James'
cn - condition, napr. 'eg' = equals, 'gt' = greater than, ...
on - operator, napr. 'a' = AND, 'o' = OR

V tomto pripade by sa cely dotaz zapisal do URL a po zavolani GET
request by sa vratil vyfiltrovany obsah. Tento sposob mi pripada asi
najviac RESTful, ale ta url by bola asi dost dlha v niektorych
pripadoch.

2) dotaz zakodovat do XML






V tomto pripade by sa muselo XML asi poslat cez request POST alebo PUT a
nasledne spracovat, ale metody POST, PUT sluzia na ine ucely a asi to
nie je 'validne' REST riesenie.

3) nejak inak :) rad sa necham poucit ...

RM

Jsem moc rád za tento dotaz - zdá se, že s RESTem konečně začíná koketovat
více a více lidí.

Jeho problém je hned v několika omylech, které pramení z chýru kolem RESTu:
a) REST != CRUD . REST je o definici malého množství operací nad všemi
zdroji daného systému. Jako příklad uvedu HTTP operace HEAD a OPTIONS.
b) REST != HTTP . HTTP je pouze jedním z RESTových protokolů, který se typicky
používá jako transportní protokol pro jiný RESTový protokol.
c) URI nereprezentuje přesnou datovou podobu zdroje pro READ operace.
URI reprezentuje zdroj jako takový, je to tedy jeho identifikace. Každá operace může být parametrizována. Podstatne je, aby opakované READ operace na stejný zdroj vracely btť různé, ale sémanticky shodné reprezentace zdroje. Jako příklad opět uvedu onu HTTP operaci HEAD, ktera vrací pouze "metadata" zdroje.

Co z toho plyne, tedy jaké řešení navrhnout?

Pro každý typ zdroje zavést jako zdroj kolekci vsech zdroju daneho typu, na teto kolekci zavést operaci QUERY či FILTER, která bude mít logicky dva parametry:
1) URL kolekce
2) vlastní query

Pak už záleží čistě na libovůli autorově, jaký transportní protokol použije (no dobře, bude to HTTP, že? :-D ) a jak se naimplementuje (tak jo, jak se na HTTP udělá binding onoho protokolu). Pro HTTP lze použít jak query string GETové operace (ta je mimochodem také dvouparametrová, URL a QUERY_STRING, přičemž druhý parametr je nepovinný) nebo POST a query posílat v datech.

oRESTovaná externalizace dat aneb když to másh nahoře

Další díl z cyklu oRESTování začnu možná trošku zmateně a vyhlásím soutěž o druhou nejlepší RESTovou aplikaci, přičemž je nám všem jasné, že webové prohlížeče (webové stránky jako takové) jsou tou první.

Tak co, už jste na to přišli?

Nechám Vás ještě chvíli se trápit...

Tak dobře. Nebudu Vás dlouho napínat, jsou to Feed Readery.

Mezi námi bloggery není jediný, který by nevěděl, co to je a jen velmi málo, kteří nepoužívají žádný. No ale pro jistotu pro ty, kteří nevědí, o co se jedná, malá naučná vsuvka.

Před dávnými a dávnými lety vznikl ve vývojovém centru firmy Netscape protokol Rich Site Summary (RSS, košatý popis stránky), který umožňoval v kostce popsat obsah stránky. Nejdůležitější částí byl vlastní popis, používaný pro jejich portál (snad vůbec první skutečný portál) my.netscape.com. Jako podružné se tehdy jevily popisy částí stránky.

Postupně se ale se zaváděním publikačních systémů (a hlavně blogů) karta obrátila. Protokol byl přejmenován na Really Simple Syndication (skutečně jednoduchý výcuc, opět RSS, to je ale náhodička, co?) a jeho hlavní náplní se stalo informovat čtenáře stránek o novinkách. Realizace je vskutku jednoduchá - RSS stránky (říká se mu feed) obsahuje ke každému článku jeho identifikátor (typicky část URL článku), odkaz na článek a datum a čas publikace. Potom aplikace, která RSS umí číst (říká se jí čtečka RSS neboli Feed Reader), si poznamená všechny položky seznamu, nabídne jejich seznam uživateli a zvýrazní ty, které nově přibyly a nebo si je ještě nepřečetl. Feed Reader se tedy chová obdobně jako poštovní klient, až na to, že místo do poštovní schránky chodi na URL s RSS Feedem. Po novu se prosazuje ATOM, rozšíření RSS, které kromě vylepšené syntaxe feedů zavádí Atom Publishing Protocol umožňující nejen číst, ale i vytvářet a měnit RSS (Atom) Feedy.

O tom, že systém RSS feedů je RESTová aplikace, snad není pochyb. Distribuce RSS jako u webu (RSS má své URL), přesně definované rozhraní (dokonce i struktura dat), operace jedna jediná - GET, a to buď na RSS feed, stránku nebo její část, bezestavovost komunikace, kešovatelnost, ...

Co má ale společné seznam nových článků na blogu a externalizace (vyvezení ven) dat, Holmesi? To je přeci zřejmé, můj drahý Watsone.

Na blog a jeho články se lze také dívat (a bývá to tak implementováno) jako na relační tabulku, kde jeden řádek databáze odpovídá jednomu článku. Potom vlastně jednotlivé položky RSS feedu nejsou nic jiného než řádky této tabulky nějak převedené na klasické RESTózní zdroje (jeden článek, jedno URL, na němž GET vrací obsah tohoto článku) a ty pak nějak přetransformované do struktury RSS. Odtud je již jen krůček k zobecnění, kdy JAKOUKOLI tabulku, dokonce jakýkoli výsledek SQL dotazu jsme schopni převést do podoby RSS feedu.

A bác ho. Když jsme schopni jakákoli data převést do RSS, můžeme je pak KOMUKOLI na světě v této podobě předat (a navíc mu stačí poslat jenom URLčko a on už vždy bude mít RESTově-aktuální data!) a on si je bude schopen prohlédnou ve svém Feed Readeru.

Navíc můžeme jít ještě dál a říct, že díky pevně dané struktuře RSS lze tato data strojově zpracovat obdobným způsobem, jako by nám je vrátila WebServisa.

Díky transportnímu protokolu HTTP máme ještě k dispozici HTTP-Basic autentizaci a všudypřítomné HTTPS, takže máme bezpečnost dat téměř zadarmo. No není to krása?

Ale svět jde ještě dál. Vznikl nový Buzzword MASHUP. Mashup je stránka či celá webová aplikace vzniknuvší jako syntéza dvou i více webových stránek (aplikací). Typickým příkladem budiž Internetový obchod, který jenom přeprodává zboží jiných Internetových obchodů.

Mashup pak samozřejmě musí nějak získat data od "podřízených" aplikací a rozumět jim. Existují mešupovače (óch, jak je ta na naše řeč bohatá a krásná, že jo, dědo Kovando!), které dokáží vytáhnout data přímo ze stránek, ale nejlépe se pracuje se strojově zpracovatelnými daty, které pro mé potřeby (nebo obecně) někdo zveřejnil, neboli externalizoval. No a nejlépe, pokud tato data mají nějaký rozumný rozšířený formát, kterému rozumí každý. Třeba RSS. A když mashupem je zase RSS, máme tu nádhernou distribuovanou RESTovou aplikaci, ve které máme jediný formát zveřejněných dat - RSS, kde každý si jej může a umí stáhnout, přetransformovat do jiného RSS a to zase zveřejnit...

Na závěr zbývá už jenom jedna otázka. Kolik procent sebere ATOM SOAPu? IMHO není důvod na B2B používat SOAP. Také většina infrastrukturních WebServis jsou stejně jenom donory, dekorátory či akceptory dat, což lze krásně a jednoduše řešit právě ATOMem. A pokud doprostřed celého toho intranetového světa umístíte ATOM repositoř (náhrada za WebDAV), dosáhnete úžasné flexibility.

Jak oRESTovat Javí aplikaci

Dneska ráno jsem našel naprosto zajímavý článek, první ze série o RESTu, který objasňuje REST na příkladu jeho převedení do světa Javy.

První díl vzali autoři z trošku jiného konce - začali od Bindingu neboli vazby mezi klientem a serverem. Vazbu v RESTu definují jako asociaci logického jména na něco "fyzického", třeba kusu kódu, kus paměti či metodu.

Dávají do kontrastu vazbu mezi jménem třídy v Javě (a klasický ClassLoading) proti volné asociaci mezi URLčkem a "stránkou" Webu. Zasmál jsem se nad přirovnáním, že změna implementace třídy (v jejich příkladě java.util.Date) znamená (bez šíleného overheadu s vlastní implementací ClassLoaderu) restart celého JVM, což v případě Webu je věc naprosto komická. No schválně si představte restart celého Webu. Ten synchronizační komunikační protokol bych chtěl vidět... tedy nechtěl...

Takže si řekli, že:
1. Browser se zeptá Domain Name Service (DNS) na "tapikuv.blogspot.com" (v jejich případě www.theserverside.com, ale co bychom si to neupravili, že :-D) a zpět získá IP adresu.
2. Browser vytvoří TCP/IP spojení na onu IP adresu na portu 80.
3. Spojení použije na odeslání HTTP GET requestu na zdroj "/" na tapikuv.blogspot.com.
4. Server dostane HTTP request, něco s ním udělá a vrátí nějakou reprezentaci zdroje "/".
5. Browser ji dostane, něco s ní provede a zobrazí to uživateli.
6. nakonec browser shodí TCP/IP spsojení a "un-binds" (poměrně hodně podstatné slovo, viz níže) od endpointu.

Takže si kluci zavedli vlastní URI schéma "resource" (např. resource:/customers) a navrhli pár tříd:
1. Context (něco mezi JNDI kontextem a proxy)
2. Request (obdoba HTTP requestu)
3. Representaion (obecná třída, ve své podstatě obdoba java.lang.Object)

Celý proces pak probíhá tak, že na kontextu vytvoří request na konkrétní URI, přidají k němu co potřebují, nechají jej provést a zpět dostanou Representation.

Na první pohled nic nového pod sluncem, máme EJB sdílející s klientem jenom mezixicht (miluji toto slovo, které jsem před víc než 20 lety našel ve VTMku), JNDI Context.lookup(), zavolání metody EJBčka a návrat nějaké hodnoty.

Fígl je v tom, že v tomto systému je jenom jeden mezixicht, sdílí jej tedy VŠECHNA EJBčka. To umožňuje dramaticky omezit různá omezení. Klient se tak de jure nestará o evoluci takovýchto EJBček. Stačí mu jenom znát správné URIčko a umět se vypořádat s instancemi Representation.

Sranda je v tom, že výhody tohoto systému nepochopil téměř žádný diskutující. Odvolávky na zahození typovosti v Javě,když ji přece sami autoři používají, že do Javy to vůbec nepatří, že je to přece k ničemu, když ti server vrátí něco, co ty dopředu nevíš, že vrátí, či na to, že to všechno řeší přece CORBA, DCOM a SOAP, jsou velice srandovní. Šlo přece o vysvětlení na příkladu architektonického stylu. Težko přece budeme dělat RESTovou servisu na operátor ++, že...

Na druhou stranu se autoři zapomněli zmínit o jedné podstatné věci, a tou je právě onen "un-bind". Tato operace totiž není v RESTu definována, kde je nahrazena operací "rebind". Chápu, že ona jemná nuance nemusí být pro mnohé čitelná. Hlavní rozdíl je v tom, že ona vazba mezi logickým jménem a "fyzickou" reprezentací má obvykle trvání přesahující jeden request. Teprve když si klient usmyslí, že je načase aktualizovat odkaz, udělá onen "rebind". Kromě kešování bindingu tu navíc máme ještě kešování reprezentací, kdy zase klient rozhoduje, zda je na čase se podívat po aktuální verzi.

No a samozřejmě mám trochu potíž s onou třídou Context. Podle mne je mnohem lepší ji rozdělit na Registry, Repository a Proxy. Registry mi řekne "fyzičtější" odkaz (zde dělám rebind), Repository mi vrátí Proxy (které si kešuji) a na Proxy pak volám requesty. Přijde mi to logičtější a více RESTózní.

Krátké oRESTování

O RESTu se všude vedou dalekosáhlé debaty. Například zde se Vlasta Vávrů snaží přijít oné věci na kloub.
Nejsem sice kdovíjaký REST-guru, ale svoje si k tomu řeknu:
* REST je o zdrojích (resourcech). Každý zdroj má svou jednoznačnou identifikaci - URI. Po dobu jeho životnosti pod tímto URI vždy a za každých okolností najdete tento zdroj (jestli je to URLčko nebo URN do repozitáře je buřt). Každý zdroj JE STAVOVÝ. Minimální sada stavů je jsem - budu - byl jsem. Představíme-li si jako zdroj seznam členů CZLUGu, je jasné, že se bude v čase měnit. Ale pokaždé dostanete logicky totéž, aktuální seznam členů. No, aktuální, RESTózní architektura umožňuje plnohodnotné interceptory, kde například může stát cache, která vrátí seznam klidně včerejší. I o tom REST je. Data nemusí být vždy aktuální.
* důležitou vlastností RESTózních aplikací je omezená množina operací, které lze s daným zdrojem provádět. Proto je HTTP RESTózní, má čtyři hlavní operace GET, POST, PUT a DELETE.
* komunikace MUSÍ BÝT BEZESTAVOVÁ, tedy komunikace nesmí zahrnovat stav klienta. To ale neznamená, že sezení jako takové je v RESTu nesmysl. Pouze jeho řešení pomocí sušenek je nepřípustné. Mám-li sezení zakomponováno do URL, jsme v pohodě. Samo sezení se stává zdrojem. Dostávám se tak do situace, kdy logická operace přidej produkt s URI:XY do košíku patřící sezení s URI:SSS (třeba HTTP POST SSS produkt=XY) bude mít za následek vždy to totéž a o to právě v RESTu jde. Dalším problémem pro bezestavovost komunikace jsou <INPUT TYPE="HIDDEN">. Tyto jsou v HTML zavedeny právě pro udržení stavovosti komunikace, čili typická antiRESTóznost.
Doufám,že si někdy najdu čas a všechno, co o RESTu vím, sem napráskám.