On Tue, Aug 19, 2008 at 10:15:37AM +0200, Richard Mihalovič wrote: > Diky za vycerpavajucu odpoved, za to uz by si si zasluzil aj nejake > pivo :)
Hmm. Jakozto abstinent... :-D > Na dnes snad uz len jedna otazka :) Ake api/frameworky/tooly pouzivate > pri vyvoji REST aplikacii? Ja momentalne pouzivam tieto veci: > > server/klient cast(JAVA): Restlet (http://www.restlet.org/) > binding XML (JAVA): JAXB > klient (FIREFOX): Poster > Ty, kteri mne znaji a znaji me nazory, jiste nepreqapi, kdyz napisu,ze JSDK ;-) Ale uz mam v ToDo listu se do konce roku podivat, jesti neni neco, co by mi usetrilo praci a umelo se chovat tak, jak bych ja potreboval. Oto 'tapik' Buchta > RM > > On Tue, 2008-08-19 at 09:39 +0200, Oto Buchta wrote: > > On Mon, Aug 18, 2008 at 11:51:15PM +0200, Richard Mihalovič wrote: > > > 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. > > > > Presne tak. REST neni o tom, v jake reprezentaci prenest data z jedne strany > > na druhou, ale jakym zpusobem aplikaci navrhnout. > > > > > Popripade ak by si mohol uviest nejake zdroje: knihy, best patterns > > > ktore sa oplati precitat. > > > > Mam-li byt uprimny, tak krome bible RESTU (Fieldingova Dizertacka, kde REST > > definuje) jsem ja osobne zadnou knihu necetl. V dobach, kdy jsme s RESTem > > v Systinetu zacinali, to jeste nebyl buzzword, takze se o nem knihy > > netiskly. > > > > Staci se podivat na amazon - > > http://www.amazon.com/s/ref=nb_ss_b?url=node%3D1000%2C5%2C3510&field-keywords=REST&x=9&y=17 > > a clovek zjisti, ze jich ani > > moc neni. Kazdopadne podle referenci znamych neni RESTful WebServices > > (na amazonu v searchi na REST je hned prvni, takze asi tak) vubec spatna. > > > > V cestine jsem nic o RESTu nevidel. > > > > > 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 :) > > > > Ano. Proto jsem psal o CHYRU okolo RESTu. REST je dost casto zjednodusovan > > na HTTP a z toho prameni jeho nepochopeni. > > > > Na druhou stranu nikde nerikam, ze mam patent na rozum (natoz na REST), > > takze i moje tvrzeni nemusi vzdy odpovidat. Proto kazde opraveni vitam. > > > > > 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 :). > > > > Ono se samozrejme pouziva obeho pristupu. Pristup referenci je naprosto > > jasny: > > zdroj neni nic jineho nez BAG (collection) jinych zdroju. Vyhoda je v tom, > > ze onen zdroj, onen batoh, zkratka nezajima, jak ony zdroje vypadaji. > > Vem si, ze by tvuj batoh mel vedet dopredu vsechno o vsech vecech, ktere > > do nej nekdy v budoucu prijdou a mel s nimi umet pracovat. One je proste > > umi jenom uschovat v sobe. > > > > Druhy postup byva principialne jakasi proxy, ktera umi vzit onen batoh a > > jeho > > obsah a pokud rozumi vsemu, co uvnitr je (coz u objednavky a jejich polozek > > lze ocekavat), umi je vratit kompletne vyrenderovane. Dost casto byva tato > > proxy implementovana jako "jina reprezentace" onoho batohu. Predstav si to > > tak, ze onen batoh ma URI http://mujstroj/mojeaplikace/mujbatoh a pri > > ziskavani > > jeho obsahu pouzijes dva parametry - ?withLinks nebo ?withContent > > > > Je to uz jasnejsi? > > > > > > > > 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 > > > > Jak uz jsem psal ciste zalezi na tobe. Osobne bych doporucoval spojeni > > obeho, > > kdy 404 nemusi nic obsahovat, kdezto 201-Created by mohl vracet byt cely > > obsah > > vyvtoreneho zdroje nebo minimalne jeho URL, protoze typicky se operace > > CREATE > > implementuje na kolekci zdroju daneho typu. > > > > > 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 ? > > > > Samozrejme. Napriklad WebDAV ci FTP, ktere maji dokonce i svuj vlastni > > transportni protokol ;-) Pokud se jedna o REST over HTTP, pak naprilad > > ATOM. > > > > > No na dalsie veci sa radsej spytam nabuduce ;) > > > > Uz se tesim ;-) Kazdy dotaz se pak pokusim nejak rozebrat v oRESTovani, > > ale az na to bude cas ;-) A ze bych to pak vydal knizne ? :-D LOL > > > > Oto 'tapik' Buchta > > > > > > > > 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
