REST - HATEOAS és range request elvek ütközése
Ha valaki nem lenne tisztában a két elvvel:
A HATEOAS kb azt mondja, hogy ahhoz, hogy egy REST service-hez könnyen tudjunk klienst készíteni, úgy kell válaszolni a kérésekre, hogy visszaadjuk bennük, hogy milyen további interakciók lehetségesek az erőforrással kapcsolatban. Ez egy lapozható gyűjteménynél pl így néz ki:
GET /users?offset=0&limit=25
200 okÍgy nagyon egyszerű egy lapozót generálni, mert az aktuális oldalak lekéréséhez mindenhol megvan a megfelelő link, csak hozzá kell csapni egy GET-et. Az egyes item-eknél is ott van a link, amivel részletesebb tartalmat lehet lekérni, és így tovább...
A Range Request-eknél a lapozzás kapcsolatos információ a header-ekben utazik valahogy így::
GET /users
Range: items=0-24
206 partial content
Content Range: items=0-24/138A modern böngészők tudják kezelni a cache-ükben mindezt, úgyhogy az nem indokolja, hogy url-be tegyük a kérésnek ezt a részét.
A kérdés az, hogy szerintetek milyen legyen a visszatérő json formája ahhoz, hogy a HATEOAS elve ne sérüljön, tehát a következő lapra mutató link automatikusan generálható legyen belőle?
■ A HATEOAS kb azt mondja, hogy ahhoz, hogy egy REST service-hez könnyen tudjunk klienst készíteni, úgy kell válaszolni a kérésekre, hogy visszaadjuk bennük, hogy milyen további interakciók lehetségesek az erőforrással kapcsolatban. Ez egy lapozható gyűjteménynél pl így néz ki:
GET /users?offset=0&limit=25
200 ok
{
href: "/users/",
offset: 0,
limit: 25,
first: {
href: "/users?offset=0&limit=25"
},
next: {
href: "/users?offset=25&limit=25"
},
previous: null,
last: {
href: "/users/?offset=125&limit=25"
},
items: [
{
href: "/users/1",
id: 1,
name: "Jánszky László",
registrationTime: "2014-10-28 10:00:01"
},
...
{
href: "/users/26",
id: 26,
name: "Krieg Antónia",
registrationTime: "2015-01-09 01:00:11"
},
]
}
A Range Request-eknél a lapozzás kapcsolatos információ a header-ekben utazik valahogy így::
GET /users
Range: items=0-24
206 partial content
Content Range: items=0-24/138
{
//felhasználó lista
}
A kérdés az, hogy szerintetek milyen legyen a visszatérő json formája ahhoz, hogy a HATEOAS elve ne sérüljön, tehát a következő lapra mutató link automatikusan generálható legyen belőle?
Majdnem mindegy :)
Én akkor választanám a Range Request-et, ha tudnám, hogy a jövőben olyan kliensek fogják használni az apit, amiknek kényelmesebb a fejlécekben feldolgozni ezt az információt.
A kliensek általában az api
A mostani helyzet kivétel, mert én fogom a klienst is csinálni, amihez viszont semmi kedvem nincs :D megnézem, hogy ez https://github.com/weluse/hyperagent hogyan kezeli a lapozást, és úgy fogom implementálni a szerver oldalt. Remélem sokat tud ez a kliens, rohadtul nincs kedvem sajátot írni.
Btw egy gyengébb klienst még akár xslt alapon is ki lehetne hozni a dologból, ha xml lenne a formátum. A hal-t megcsinálták xml formában is microsofték... Csak hát akkor nem lehetne olyan szép űrlapokat csinálni, meg csilli-villi design-t... Legalábbis nem nagyon ástam be magam a single page xslt alkalmazások rejtelmeibe. Gondolom az alap ugyanaz lenne, mint amúgy, hogy js-el lerántom az xml-t, aztán feldolgozom, az eredményt meg valahogy beszórom a body-ba, vagy a content részbe... csak hát a dolog ennél bonyolultabb, mert menet közben még a menüt is át kell írni, stb...
Egyelőre REST json-al kapcsolatban még nem teljesen tiszta a kép, hogy mondjuk a menü adatait, vagy az adatok típusát OPTIONS-ben küldjem e át, vagy mégis miben. Pl xml-ben ez nagyon egyszerű lenne típus névtérrel, menü névtérrel, meg ilyesmikkel fel lehetne szórni a nyers adatot... Azt hiszem névterek helyett rest-nél a rel-t szokták használni inkább a linkeknél. Még sokat kell olvasnom a témában :S
Úgy nézem itt a típusokat class attribútumban megadott url-el csinálják: hypermedia-apis, pl form.class, header.profile, stb... Ezek helyett szerintem sokkal szerencsésebb lenne a külön névtér kialakítása minden egyes alkalmazáshoz. Szóval lenne egy külön névtér a típus leírásra, és egy külön url, akár másik domain-en is, amiből ki tudja nyerni a kliens, vagy a felhasználó, hogy mit hogyan kell értelmezni, megjeleníteni, stb... Ebben a példában human readable documentation van benne, de simán lehetne ez alapján automatizáni a klienst. A másik lehetőség az, hogy OPTIONS-ben küldjük el ezek a típusokat. A harmadik meg hogy a válasszal együtt külön névtérben.