Dik za odpoved, rad si precitam aj tu doplnenu cast, lebo som nejak vsetko nepodchytil ... :) v podstate ak som spravne pochopil je len na mne ci budem parametre predavat pomocou GET alebo POST.
Popripade ak by si mohol uviest nejake zdroje: knihy, best patterns ktore sa oplati precitat. Zatial co som cital rozne zdroje (hlavne web) tak mam pocit ze REST je natolko volny az je z toho miestami anarchia a chaos a kazdy si to vysvetluje po svojom :) A ked uz som natrafil na cloveka ktory sa REST-u venuje, by som sa spytal este na par veci ktore mi nie su uplne jasne: 1) referencia namiesto obsahu preco sa vo vacsine xml/json suborov uvadza referencia na zdroj na miesto obsahu ? napr. <order ref="http://....";> <item ref="http://server/item/1"/> <item ref="http://server/item/2"/> <item ref="http://server/item/3"/> </order> a nie uplny obsah napr: <order number="abc" id="123"> <item> <id>1</id> <catalogNumber>a123</catalogNumber> <price>12,55</price> ... </item> ... <item> </item> </order> Mi pripada logicke nacitat viac udajov naraz, ako sa potom dotazovat na kazdy zaznam po jednom requeste (teda aspon mam pocit ze by to mohlo byt rychlejsie :). 2) navratove kody operacii Tu su znova dve moznosti, bud budem vracat vysledok kazdej operacie ako HTTP status code/header (404-Not found, 200-Ok, 201-Created, 202-Accepted,...) alebo ako XML subor typu: <response code="error"> <error>resource not found</error> </response> alebo dokonca ako kombinaciu HTTP status code a XML 3) protokol > HTTP je pouze jendim z RESTovych protokolu, ktery se typicky > pouziva jako transportni protokol pro jiny RESTovy protokol. existuje aj nejaky iny protokol ktory sa realne pouziva ? No na dalsie veci sa radsej spytam nabuduce ;) RM On Mon, 2008-08-18 at 11:07 +0200, Oto Buchta wrote: > Tvuj problem je v nekolika omylech, ktera prameni z chyru kolem RESTu: > a) REST != CRUD . REST je o definici maleho mnozstvi operaci nad vsemi > zdroji daneho systemu. Jako priklad uvedu HTTP operace HEAD a OPTIONS. > b) REST != HTTP . HTTP je pouze jendim z RESTovych protokolu, ktery se typicky > pouziva jako transportni protokol pro jiny RESTovy protokol. > c) URI nereprezentuje presnou datovou podobu zdroje pro READ operace. > URI reprezentuje zdroj jako takovy. Kazda operace muze byt parametrizovana. > Podstatne je, aby opakovane READ operace na stejny zdroj vracely byt ruzne, > ale semanticky shodne reprezentace zdroje. Jako priklad opet uvedu onu > HTTP operaci HEAD, ktera vraci pouze "metadata" zdroje. Dalsim prikladem > z HTTP je moznost rict si o preferovany jazyk vysledku. > > Co z toho plyne? > > Zaved si pro kazdy typ zdroje jejich kolekci, na teto kolekci zaved operaci > QUERY (nebo FILTER, jak chces) a tato operace bude mit logicky dva parametry: > 1) URL kolekce > 2) vlastni query > > Pak uz zalezi ciste na tobe, jaky udelas binding na HTTP. Muzes pouzit query > string GETove operace (ta je mimochodem taky dvouparametrova, URL > a QUERY_STRING, pricemz druhy parametr je nepovinny) nebo POST a query posilat > v datech. > > Na http://tapikuv.blogspot.com/2008/08/orestoven-dotazy.html to zkusim behem > tydne trochu vic rozvest. > > On Sat, Aug 16, 2008 at 02:25:03PM +0200, Richard Mihalovič wrote: > > 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 > > > > <query orderby="..."> > > <filter variable="..." string="..." condition="..." operator="..." /> > > <filter variable="..." string="..." condition="..." operator="..." /> > > </query> > > > > 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
