Až Vám zčerná obrazovka, přejděte na Linux!

Proč používat Linux

neděle 17. srpna 2008

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.

Žádné komentáře: