Szerintem te is félreérted.
Pont arról szól a REST (és a skálázhatóság), hogy a döntések kliens oldalon vannak. Az erőforrások állapotai csak az erőforrás műveletek segítségével változhatnak meg, és ezen műveletekben teljes erőforrás-reprezentációkat küldünk el a szervernek.
REST components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components.
Azaz a kliens számolja ki, hogy amikor A erőforrás állapota S1-ről S2-re változik, akkor S2-nek (intended state) hogy néz ki a reprezentációja. A kliens tudja, hogy egyáltalán S1-ről milyen S2 állapotokba lehet az erőforrást átküldeni, és utána azt hogyan kell reprezentálni.
A szerveren nagyon kevés "döntés" van, az ő feladata az erőforrások állapotai reprezentációinak kiszolgálása és az állapotátmenetek fogadása a kliensektől.
Az, hogy a " kliensek csakis azokon az állapotokon mehetnek át, amelyeket a szerver által küldött hipermédia tartalmaz hivatkozások alakjában." totálisan ellentmond annak, amit a REST mond. Ha a szerver számolja ki a jelenlegi állapot alapján az összes lehetséges következő állapotot, annak semmi, de semmi értelme nincs.
Például van egy erőforrásom, ami egy 16 bites, előjel nélküli egész számot tárol, például egy raktárkészlet-mennyiséget. Mindegyik 16 bites előjel nélküli egész szám érvényes állapottér-elem, és bármelyik állapotból bármelyikbe érvényesen el lehet jutni, az egyes állapot-módosulások a raktárkészlet-mozgásokat jelzik. A szerver az összes lehetséges 16 bites egészet, mint új lehetséges állapotot elküldi a kliensnek mint hivatkozást, hogy a kliens válasszon közülük? Ezt te sem gondolhatod komolyan! Nonszensz.
Azt, hogy mi az új állapota az erőforrásnak, azt a kliens számolja ki, ő dönt róla, hogy mi legyen, és neki is tudnia kell az érvényes állapotátmeneteli lehetőségeket. Az előfordulhat, hogy a szerver elutasítja, hogy a kliens egy-egy állapotátmenetet megvalósítson, mert nem teljesülnek feltételek (megváltozott például az erőforrás állapota azóta, hogy a kliens erről értesült volna, vagy éppen az erőforrás már nem létezik, vagy az erőforrás már más címen érhető el, esetleg a kliens már nem jogosult végrehajtani az állapotátmenetet).
A hivatkozások a HATEOAS-ban arra valók, hogy megmutassák, mik a kapcsolt erőforrások (és nem azt, hogy mik a mostani erőforrás esetleges jövőbeni állapotainak a megváltoztatását leíró URI-k). Az URI-kban (hivatkozásokban) sosem az erőforrás konkrét állapotára hivatkozunk, hanem az erőforrásra magára, ami egy adott erőforrás kontextusában még a kliens számára érdekes lehet. De sosem az állapotátmenetekre vonatkoznak a hivatkozások! Az egy teljesen nonszensz dolog.
"kliensek csakis azokon az állapotokon mehetnek át, amelyeket a szerver által küldött hipermédia tartalmaz hivatkozások alakjában.""
Az, hogy mi a kliens állapota, majd a kliens tudja. A kliens tart nyilván minden munkameneti állapotot is. A kliens tartja nyilván, hogy ő még hány más szervertől kért le erőforrás-állapotokat, amikor dolgozott és a szerverektől erőforrás-állapot módosítást kért.
A szervernek semmi köze ahhoz, hogy a kliens milyen állapotban van, és milyen állapotokba mehet, a szerver semmit nem tud a kliens állapotteréről (pont a réteges felépítés miatt). A szerver csak a szerver által kezelt erőforrásokról és azok állapotteréről tud, a kliens állapotteréről semmit nem tételezhet fel (ha bármit feltételezne a kliens állapotteréről, akkor megvalósulna a szerveroldali munkamenet-kezelés, hiszen az pont arról szól, hogy a szerver nyilvántartja, hogy mi az állapota a kliensnek!).
Ez pont a REST-tel homlokegyenest ellentétes dolog lenne, hogy a szerver bármit is korlátozni akarna a kliens állapotai közül.
A kliens tudja, hogy egy adott erőforrást egy S1 állapotból az S2 állapotba akarja átvinni, hiszen ő (és csakis ő) dönt arról (akár más szerverekről hozott más erőforrások értéke alapján), hogy mi az új állapot. Például a raktáras példánál maradva megnézi, hogy a szállítmányozási rendszerben mi az állapota egy megrendelésnek, és ez alapján módosítja a raktárrendszerben az állapotot.
A szerver sosem számol ki semmiféle erőforrás-állapotot, ez nem dolga neki, sőt, nem is tudja megtenni, hiszen nincs meg hozzá minden információja. Az erőforrások állapota csak a kliensek által módosítható (és az is csak teljes reprezentációk által), és azt csak a kliens tudja, hogy milyen állapotátmenetnek kell történnie.
REST esetén az alkalmazás logikája a kliensekben van, a szerverek feladata az erőforrások és azok állapotainak a nyilvántartása, és a kliensektől érkező állapotmódosítási kérések (amelyek mindig teljes reprezentációk!) befogadása vagy elutasítása.
Ez totál hasonlít ám ahhoz (de nem feltétlenül ugyanaz, ezt nem állítom), hogy egy adatbázis is csak egy tárolási réteg, és az alkalmazási logikát az ahhoz kapcsolódó backend (ami ténylegesen az adatbázis kliense) valósítja meg.