Weblabor

Azt hiszem ez ugyanaz a probléma, amibe régebben is belefutottam, csak más köntösben. Ott még a statikus html támogatása is kérdés volt, meg a service és a client is egyben volt. Ott sem jutottam igazán megoldásra, max arra, hogy egy oldalon jelenítek meg mindent, így nem kell az aloldalakat külön letárolni az url-ben. Ez viszont nem lenne túl szép. A másik változat az volt, hogy header-ben kell átküldeni az adatot, de ott nem gondoltam eléggé át, hogy az állapotot is le kell tudni írni, így csak az url a megfelelő forma.

Jelenleg én úgy állok, hogy az összes aloldalnak meg kell jelennie valamilyen formában az url-ben. Az ilyen aloldalak mind csak GET-es erőforrások. A client-hez tartoznak szorosan, de kapcsolatban vannak a service-ben lévő erőforrásokkal is. Ezeknek kellene valahogyan megjelenni az url-ben.

A sort és a limit egyértelműen queryString után kell, hogy jöjjön, ez legalább letisztult közben. Hash-t nem lehet használni, hogy kompatibilis legyen a pushState nélküli változattal. Header-t sem lehet használni, mert nem az url része, ahogy külön method-ot sem, szóval azok kiestek. A queryString sem jó szerintem, mert az erőforrás szűrésre, rendszerezésre, stb jó, itt viszont az erőforrás, amihez kapcsolt a dolog nem változik.

Így ez a három jelölt maradt:


Az elsővel az a baj, hogy a rest service szerinti megközelítés az egyre szűkíti az adatokat:


a profile nem szűkít adatot, sőt nincs is ilyen tulajdonsága az felhasználóknak, tehát nem stimmel.

Ezzel a logikával viszont bejött két újabb:



Ezeknél ugyanaz a helyzet, mint az előzőnél: az inf3rno-nak semmi köze nincs a profil oldal tulajdonságaihoz, mert adat azonosító.


Szerintem ezek a megoldások elfogadhatóak (a saját REST-es elképzeléseimmel):


Az első változat, ami szerintem a helyes, mert hasonló a profile-userData és a users-sort viszonya. A másik két megoldás, ami inkább megszokott, de mégsem keveredik bennük a path-ban az erőforrás és a pluszban felhasznált adat.

Jelenleg olyan szerencsés helyzetben vagyok, hogy az url kinézete nem számít, úgyhogy az első változatot fogom alkalmazni. Ha számítana, akkor meg a megszokott lenne egy kis módosítással:



Az hiszem olyan helyzetben, ahol több erőforrást jelenítünk meg egyszerre, mindig választani kell egy fő erőforrást, amit beteszünk a path-ba, a mellék erőforrásokat pedig betehetjük nyugodtan a queryString-be.

Mint most kiderült, alapvetően a kérdés két erőforrás egyszerre történő megjelenítésére vonatkozott:

Az egyik az adat szolgáltató, a másik a megjelenítő, és ha history-ba akarunk menteni egy állapotot, akkor mindegyiket kénytelenek vagyunk az url-be tenni.

Ezek alapján a legmegfelelőbb leírási forma:

Csak kibogoztam :D

Ismét sikerült megválaszolnom a saját kérdésem :D
Amúgy érdekel, hogy ti mit gondoltok a témáról, sokan a múltkor sem értették, hogy mit szöszölök ennyit az url-eken :D

Egyébként ezért nincs szerintem még REST szabvány, mert ilyen ellentmondások vannak a rendszerben. Én amit eddig REST-ről láttam, abban az volt, hogy path - erőforrás, queryString - kérés leírása (sort, limit, keresőkifejezés, stb...), header - megjelenítési mód, pl accept header-ben az elvárt mime típus küldése. Ennél a history-s problémánál viszont csak az url-t lehet felhasználni, és a megjelenítési módot is abban kell átküldeni, nem pedig header-ben, úgyhogy ez a változat is bukott egészen addig, amíg nem építik be a böngészőkbe, hogy a history bizonyos az aktuális állapottal kapcsolatos header információkat is letároljon. Szerintem még jó darabig nem lesz ilyen, úgyhogy REST szabvány sem, vagy ami lesz, ott biztos, hogy az url valamelyik részét egynél több dologra fogják felhasználni.