ugrás a tartalomhoz

REST - HATEOAS és range request elvek ütközése

inf · 2013. Okt. 5. (Szo), 02.31
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
  1. {  
  2.     href: "/users/",  
  3.     offset: 0,  
  4.     limit: 25,  
  5.     first: {  
  6.         href: "/users?offset=0&limit=25"  
  7.     },  
  8.     next: {  
  9.         href: "/users?offset=25&limit=25"  
  10.     },  
  11.     previous: null,  
  12.     last: {  
  13.         href: "/users/?offset=125&limit=25"  
  14.     },  
  15.     items: [  
  16.         {  
  17.             href: "/users/1",  
  18.             id: 1,  
  19.             name: "Jánszky László",  
  20.             registrationTime: "2014-10-28 10:00:01"  
  21.         },  
  22.         ...  
  23.         {  
  24.             href: "/users/26",  
  25.             id: 26,  
  26.             name: "Krieg Antónia",  
  27.             registrationTime: "2015-01-09 01:00:11"  
  28.         },  
  29.     ]  
  30. }  
Í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/138
  1. {  
  2.     //felhasználó lista  
  3. }  
A 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?
‹ Hacktivity jegy Vállalkozás létezésének vizsgálata ›
 ■
1

Majdnem mindegy :)

laco · 2013. Okt. 5. (Szo), 13.38
Mind a kettő teljesen jól használható. A legfontosabb, hogy egy restful apiban ezek legyenek egységesen és következetesen használva az összes resource esetén.

É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.
2

A kliensek általában az api

inf · 2013. Okt. 6. (V), 13.28
A kliensek általában az api elkészülte után szokták csinálni, szóval lényegtelen, hogy melyiket választom, ha utána dokumentálom, hogy így és így kell lapozni...

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.