Mi a véleményed a HATEOAS-ról REST architektúra esetén?

Programozás

Mindenképp szükséges, a lehető legteljesebb módon kell implementálni.
3% (4 szavazat)
Többnyire jónak tartom, közepes szinten kell implementálni.
5% (6 szavazat)
Nem tudok dönteni, esetleg minimálisan kell implementálni.
5% (6 szavazat)
Többnyire rossznak tartom, esetleg néhol lehet értelme.
2% (2 szavazat)
Semmi szükség rá.
5% (6 szavazat)
Egyéb (okos lány esete, szavazok is meg nem is)
80% (97 szavazat)
Összes szavazat: 121

( Sanya v | 2014. 09. 20., szo – 18:23 )

Az utóbbi napok szavazásaiból egy mukkot sem értek.

Hát én se. Ráadásul erős a félelmem, hogy tök felesleges utánanézni, mert két nap / két hónap / két év múlva már egész más betűszavak lesznek divatban... (ja, és természetesen nem jut eszembe erről a Segédanyag- És Gyártástechnológiai Grafikus Elektronikus Megjelenítés nevű szoftver esete!)
Szerk: Off: találtam pár fórumot 2006-ból, amikben lelkes emberek a WinFS nevű technológiától kb a világ megváltását és az örök boldogságot várták, erre jött a hidegvíz a nyakukba: http://pcforum.hu/hirek/10245/A+Microsoft+torolte+terveibol+a+WinFS-t.h…

( envagyok | 2014. 09. 20., szo – 21:58 )

Erdekes kerdes ebben a formaban. Nyilvanos API-ban feltetlenul jonak es kovetendonek tartom. De egy nem nyilvanos API-ban nem feltetlenul szorakoznek vele.

( hrgy84 | 2014. 09. 20., szo – 23:13 )

Igazabol nem latom, hogy ez miert jo. Maga a definicio (marmint amit a wikipedia ad rola) nem tunik annyira strictnek, hogy hasznossagaban utolerje pl. a SOAP-ot, ahol fixen kell interfeszleiro cucc (WSDL), amibol wrapper/proxy osztalyok generalhatoak. A REST eseteben ez egyaltalan nem kotelezo, ha meg van rendes dokumentacio, akkor szinte barmilyen REST apihoz lehet klienst irni.

Nem latom, hogy ez hol szabvanyositana a REST interfeszeket.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

( enpassant v | 2014. 09. 21., v – 08:38 )

Miért is írtam ki ezt a szavazást?

A REST alapvetően a világháló működésének a leírását tartalmazza, aminél nyilvánvaló, hogy szükség van a HATEOAS-ra.
A HATEOAS köznapi nyelven azt jelenti, hogy egyik web oldalról el tudjak jutni a weboldallal kapcsolatos más weboldalakra. A weboldal tartalmazza a kapcsolódó oldalak linkjeit, amikre kattintva a böngészőben (kliens), átlép az új weboldalra (state).

A REST architektúrát elkezdték használni programok közötti kommunikációra is és itt kezd bonyolódni a kép. Lehet csak bizonyos részeit használni, nem teljesen RESTful, csak valami olyasmi. Ha így használom, akkor elesek egy-két szolgáltatástól (pl. proxy, cache, verzió kezelés, jogosultság kezelés), viszont úgy gondolom, hogy kevesebb munkaráfordítás így kialakítani.

A legtöbb munkának a RESTful-ság kielégítéséhez a HATEOAS megvalósítása tűnik és viszonylag kevés eredménnyel kecsegtet. Éppen ezért, ahogy látom ez a kérdés nagyon megosztja a REST-et használók táborát.

Magam is végigkapaszkodtam nagyjából a szavazás minden pontján, ráadásul nem sorrendben, hol ezt láttam jobbnak, hol azt.
Ami különösen érdekes, hogy a nagyok sem használják egyáltalán, pl. Google, Facebook, ...
Emiatt gondoltam úgy, hogy érdemes lehet erre felhívni a figyelmet és egy kicsit beszélgetni róla.

Jelenleg úgy gondolom, hogy mindenképp szükséges, és talán egy jól kitalált rendszerrel (pl. JAX-RS) nem is (nagy) többlet munka.

REST: in peace.

Jelenleg a REST egy elég kedvelt szó amivel jól lehet dobálózni: pl az MS féle REST-felfogás értve ezt egyrészt arra, hogy csak literal-ba bújtatott difgrammokkal lehet használni a wsdl-t (azaz Restful .net), vagy másrészt éppen arra ahogy az opendatát összeállították (csak és kizárólag 2 végű relációk léteznek, metadata layer-ről layer-re változik a Netweaverben amíg végül RPC-vé alakul... és néha ~800ms egy sima GET válasz...). Mind a kettő jó, ha a megfelelő szoftwarekkel/IDE-kkel rendelkezel és nem próbálod bonyolítani... (Nem MS ellenes vagyok, de az MS és a SAP az ahol a protokol aberrációkat tapasztalom, mivel szinte csak ezek mennek a cégnél.)

Ennek ellenére a REST jó dolog, ha nem zsonglőrködnek vele... csak a protokollból adódó overhead ne lenne. (~2k request + response header még 1 byte payloadnál is, meg persze a roundtrip+parsing ami minden esetben stateless... szóval ha nem HTTP-authot használsz, akkor a jogok eldöntéséhez egy sessionID-alapján kaparászd valahonnan elő a session-stack-et, ami legjobb esetben is O(log n) lookup + egy socket/file megnyitása még ha shm is maga az adat.)

Amit a Google próbálgat összehozni az utóbbi pár évben egyre inkább fordul szembe a REST fogalmával (jobbanmondva: egészíti ki, hogy más irányba terelje): nézz csak rá SPDY/HTTP2 szabványokra. Az (előkészülő) új trend a real-time web és schematic web együtt, ami lássuk be: REST-tel nem éppen erőforráskímélő (interval-polling / long-poll / cache-ttl etc).
Szóval erősödik a stateful irány, és jobban megéri a stateless-t is stateful csatornán használni... Így ráadásul cookie/session se kell, mert a session-stack köthető közvetlen a tcp kapcsolathoz (azaz O(0)...).
Ezeket kombinálva libuv+httpkit alapú SPDY projectek 600000 klienst tudnak egyszerre kezelni/kiszolgálni desktop teljesítményen (azaz egyesek GPU-t/OpenCL-t is használnak)... Hol van ettől a REST? (Mellesleg a Google nem éppen a desktopszerű gépekből álló farmjáról is híres?)
Mivel a tradicionális web helyett ez elég erősen in-memory és event-driven (nem is beszélve a parallelizálásról vagy bidi kapcsolatokról, ha kihasználod), ezért nem hiszem, hogy a sok wordpresses kolléga gyorsan bele tudna szokni. Szóval nem kell gyors változásokra számítani.

A HATOAS (még ha csak minimális utánajárás alapján is mondom) úgy tűnik a gépek számára jobban felfoghatóbb weboldalakra/szolgáltatásokra törekszik, ami pedig megintcsak elég fontos a sematikus vagy öndefiniáló adatkapcsolatokhoz ("Web3", ha megint szavakkal akarnánk dobálózni).

"Ennek ellenére a REST jó dolog, ha nem zsonglőrködnek vele... csak a protokollból adódó overhead ne lenne. (~2k request + response header még 1 byte payloadnál is, meg persze a roundtrip+parsing ami minden esetben stateless... szóval ha nem HTTP-authot használsz, akkor a jogok eldöntéséhez egy sessionID-alapján kaparászd valahonnan elő a session-stack-et, ami legjobb esetben is O(log n) lookup + egy socket/file megnyitása még ha shm is maga az adat.)"

Van egy megoldas ami megy lookup nelkul. A cliens belepeskor olyan ticetet kap ami tartalmazza a rolajait _alairva_. Minden server tudja mit szabad teni az adott rolokkal.
* Request header megno akkar +2KiB
* token dekodolasa es alairas elenorzese cpu ido igenyes, de cachelheto az eredmeny

hashtable elerese O(1) -nek mondott, nem feltetlenul kell tree indexet hasznalni..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( til | 2014. 09. 21., v – 08:33 )

En nem csinalnam, feleslegesnek erzem, foleg ha json a valasz. A REST nem egy szabvany, es a masik programozot csak az fogja erdekelni hogy konnyen le tudja programozni a klienst. Inkabb rendes dokumentacio legyen mint HATEOAS.

Pl. a Twitter sem tartja be a REST "szabvanyt" (nagyon nem), megis sima ugy egy Twitter kliens fejlesztese.

Volt itt egy hasonlo szavazas: RESTful API-n egy GET hívásnak lehet-e body-ja?

"a masik programozot csak az fogja erdekelni hogy konnyen le tudja programozni a klienst"

Az is fogja érdekelni, hogy verzióváltozás esetén mennyi munkája lesz az új verzióra való átállással.
Illetve az "egyik" programozót (szerver oldal) is érdekelni fogja, hogy ha verziót akar változtatni, akkor mennyi plusz munkája lesz azzal, hogy a másik programozónak minél kevesebb legyen.

HATEOAS-sal elkerülhető a verziókezelésből adódó mindkét oldali plusz munkák.

A másik nagy előnye, hogy a kliens információt kap arról, hogy milyen műveleteket végezhet az adott erőforráson.
Ha nincs róla információja, akkor pl. elküld egy erőforrás módosítást, amire a szerver azt fogja mondani, hogy nem lehetséges ilyen módosítás, vagy nincs joga hozzá. Feleslegesen zaklatjuk a szervert és a felhasználót.

A műveletekről: itt igazából értem, mire gondolsz, pl. van egy elem, amit csak megnézni lehet, szerkeszteni nem egy adott felhasználónak, ilyenkor vagy a válaszban
adom vissza, hogy mondjuk "readonly": true, vagy pedig a HATEOAS módon. Ha belső fejlesztésről van szó, tehát a szerver és a kliens oldalt ugyanaz fejleszti,
nem igazán látok gondot.

Ha csak egy interface-t adunk, és ehhez mindenki fejleszt magának, akkor is egy leírás hasznosabb (sőt, elengedhetetlen), mivel nincs séma leíró, mint a SOAP-náll, ahogy mások már korábban kifejtették.

Félreértés ne essék, én nem mondom azt, hogy ha valaki nem használja, vagy másképp csinál meg valamit az az ördögtől való.
Ha egyéni megoldást használsz az sem feltétlen kevesebb munka, mint HATEOAS-sal, és egyéni megoldásnál elvesztesz bizonyos előnyöket.
Pl. JAX-RS-nél csak annotációkat kell rakni, ami nem igazán nagy munka. Más rendszereknél viszont lehet, hogy nekünk kell kifejleszteni valamilyen rendszert (pl. Play frameworkhöz nem találok semmi használhatót), ilyenkor elgondolkodhatunk, hogy mit, mennyire és hogyan támogatunk.

A séma leírás szerintem is szükséges, de az url struktúra leírása szükségtelen, helyette azt kell megadni, hogy milyen kapcsolatok lehetségesek. Tehát aki azt mondja, hogy HATEOAS-nál nem kell dokumentáció, az szerintem téved.

"pl. van egy elem, amit csak megnézni lehet, szerkeszteni nem egy adott felhasználónak"

Még annyi kiegészítés, hogy nem csak az elemre, hanem az elem kapcsolataira is megadhatjuk.
Pl. személynél, nem csak azt mondhatjuk, meg, hogy az adott személyt megnézheti és módosíthatja-e, hanem azt is, hogy lekérhető az email címe, a barátai, vagy akár felvehetünk-e hozzá új barátot, ...

Erre a HATEOAS-ra van valami protokoll-szeruseg ezek szerint? Mert a Wikipedia leiras, amit talaltam, eleg altalanossagokban fogalmaz, az alapjan en nem tudnek ilyesmit hozzaadni semmilyen rendszerhez.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Nincs túl szabályozva, ahogy az összes többi része sem a REST-nek.

Van többféle elképzelés, ki miként gondolja jónak. Némelyiknek ez az előnye, másnak más.
Van ahol a header részbe rakják (Link header from RFC 5988), van ahol az adatok közé teszik, az xml-be (XML Linking Language (XLink)) vagy a json-ba.

Json-nál nincs szabvány, amit követni lehet, így az sem egységes, hogy milyen plusz információkat tesznek a link mellé és azokat milyen elnevezéssel. (pl. rel: reláció azonosítója, type: adat típusa (pl. application/json), method: Http method (pl. GET, PATCH), href: az url link, title: felhasználóbarát cím)

Minimum a rel és a href információ meg kell legyen, de igazán szerintem akkor jó, ha a method is meg van adva (és a type sem hiányzik ;).

Én szívesen látnék egy programot a gyakorlatban ami megvalósítja a HATEOAS-t, illetve egy klienst ami használja is. Konkrétan el nem tudom képzelni, hogy 0 információból honnan fogja tudni a kliens, hogy neki adott actionhöz melyik linket kell használnia. Vagy itt az a lényeg, hogy ezt nem is a kliens találja ki?

Ha még érdekel, akkor van egy kis példa programom, ami HATEOAS-t használ, a neve: jeeves.

Vékony kliens van, tehát a böngészőben fut Javascriptben.

Nagy vonalakban a működése:
A html oldal betöltésekor a js küld egy HEAD kérést az oldalnak, ahol a headerben visszakapja a használható linkeket.
Egy link a következő információkat tartalmazza (nem mind kötelező):

  • url
  • rel: a link kapcsolati azonosítója
  • type: a tartalom típusa (pl. application/collection+json)
  • method: a linknél használható metódusok (GET, PUT, POST, DELETE)
  • title: menü esetén a címe

Amelyik linknek van title tulajdonsága és GET metódusú, azokat jeleníti meg a menüben.
Ha egy linkre kattintunk (pl. menü), akkor a hozzá tartozó tartalom-típus alapján lecseréli a view részt és betölti az adatot.
Két tartalom típust ismer a példaprogram: a fent látott collection-t és a blog típust (application/blog+json).
Amikor betölti az adatot, akkor azzal szintén érkeznek linkek, amik megváltoztatják a menüt illetve az adott view eleminek megjelenését szabályozzák (pl. felvétel, törlés, nézet gomb vagy link).
A collection-nél például új elem felvételét, adott elem nézését, törlését és szerkesztését indító linkek vannak.

Összességében a kliens program előre nem tud egyetlen url-t sem, annyit tud, hogy az általa ismert típusú elemeket hogyan kell megjelenítenie. Ezeken a view-kon az egyes vezérlő elemek megjelenése melyik linkek meglététől függ (pl. a collection-nél, ha van [rel=item, method=DELETE] típusú link, akkor felteszi a törlés vezérlőt, és megnyomásakor meghívja az adott linket, az adott metódussal).

A fentiek alapján szépen dinamikusan változik a menü és egy adott oldal tartalma attól függően, hogy be van-e jelentkezve valaki és ha igen, akkor milyen jogosultságai vannak.

Ez a verzióváltás dolog a trükkje az egésznek. Inkább arra kéne törekedni, hogy ne refaktoráljuk naponta legalább az API-t, mert az halál.
Az ilyenhez ragaszkodó ismerőseimtől mindig meg szoktam kérdezni, hogy mit szólna hozzá, ha pl. hetente új módon kéne libc vagy mfc hívásokat használnia.
Szóval inkább egyszer legyen jól megtervezve, jól dokumentálva, és akkor nincs szükség a „varázslatokra”.

Az api változtatásokat én sem tartom szerencsésnek, de nem csak "varázslatokra" kell gondolni.

Mondok egy példát.

A példa kedvéért képzeljünk el egy ingyenes site-ot, ahová bárki regisztrálhat és kap valamekkora tárterületet, ide a https://example.com/api/login-nal lehet bejelentkezni.
Ezután a https://example.com/api/{user} oldalon érheti el az adatait a bejelentkezett felhasználó, pl. https://example.com/api/{user}/images oldalon pedig a feltöltött képeit.

Ehhez lehet írni egyszerűen egy klienst a fix url-ekkel.

Egyre több felhasználójuk lesz és egy idő után kitalálják example.com-nál, hogy fizetős szolgáltatást is indítanak, ennek a szolgáltatásnak a kiszolgáló részét más gépre tennék és egyből oda is irányítanák át a pro felhasználókat. Tehát login után a pro felhasználó az adatait nem a korábbi címen érheti el, hanem pl. a https://pro.example.com/api/{user} címen.

Itt akkor át kell írni a kliens programo(ka)t, hogy kezelje mind a két esetet és az url-eknél mindenhol két eset lehetséges. Amíg nem módosítják a kliens programot, addig a pro felhasználók nem tudják azt használni, mivel a kliens program az ingyenes felhasználók címén keresné a pro felhasználók adatait.

Ha viszont HATEOAS-sal van csinálva, akkor a kliens módosítása nélkül egyből kezelni tudja a pro felhasználókat is. Miként tudja?
A https://example.com/api/login címre bejelentkezve a válaszban szerepelni fog egy rel=index azonosítójú link, amiben benne van a bejelentkezett felhasználó home url-je. Ott fogja keresni a felhasználó adatait és ott meg is találja.

Tehát egy előre nem látható új szolgáltatást tudunk bevezetni, ahol az API url struktúrája változik, de mégsem kell módosítani a kliensen semmit.

Nem tudom, Rails alatt a HTTP reteg lekezel(het)i a redirectet, szoval ha az URL ugyanugy epul fel (ugyanolyan webapp van a masik URL alatt), akkor szamomra indifferens, honnet jon az adat, teljesen transzparensen kapom meg. A lenyeg, hogy a vegleges body-ban mar a megfelelo formatumu adat legyen. Legfeljebb a redirect lesporolasa miatt valtok cimet.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Redirecttel valóban működhet a dolog, de nem megoldás, mivel mindent duplán fog lekérdezni.
Ha pl. a sima felhasználókat 1 másodperces válaszidővel szolgálom ki, a pro felhasználókat meg féllel, akkor redirect esetén a a simák válaszideje 1mp lesz, a proké pedig 1,5mp, mivel először elmegy a sima oldalra, ott 1mp múlva átirányítódik a prora, ahonnan 0,5mp alatt megkapja a választ.

"Legfeljebb a redirect lesporolasa miatt valtok cimet."
Nem cím váltásról van szó, hiszen mind a két cím élő marad és kezelni kell. Tehát nem címet kell váltani, hanem valami vizsgálatot berakni, hogy mikor hová forduljon a kliens.

Mindenki felreertett. En elsosorban a fenti pro-nempro felosztasrol beszelek. Ha mar igy van megtervezve, hogy szintlepesnel atdob, akkor a HATEOAS es a redirect kozott adatforgalmi kulonbseg nincsen, mindketto valamilyen szintu atdobas. A HTTP redirectnek azonban a legkisebb a fejlesztesi igenye, hiszen gyakorlatilag minden framework elkezeli valahogy. Es a fejlesztett orak szamanak emelkedeset kultivaljak a gazdasagisok a legkevesbe, annal meg az is kedvesebb a szamukra, hogy dragabb az adatforgalom (tekintve, hogy a fejlesztoi oradijak az adatforgalmi dijaknal sokszorosan nagyobb).

Raadasul az uj URL kezelese igy kitolhato akarmeddig.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Akkor próbáljuk meg tisztázni!
Leírom, hogyan értem amit írtál, Te meg majd javítsd ki, hogy mit értek félre.

Nem elég berakni csak egy HTTP redirect-et, ami egyik címet a másikra átirányít, mivel két címünk van és mind a kettő használatban van. Annyit minimum a szerveren meg kell oldanunk, hogy megvizsgáljuk a bejelentkezett felhasználót és aszerint, hogy pro vagy sima, aszerint kell vagy átirányítani vagy sem.

Ha a kliens a login után a https://example.com/api/{user} oldalon keresi a felhasználó adatait, akkor a redirect átdobja másik helyre, a másik helyről a kliens megkapja a felhasználó adatait. Ez itt biztos két kérés, az eredeti cím, majd a redirectes cím.
Ezután szeretné a kliens elkérni a felhasználó barátait. Ezt a https://example.com/api/{user}/friends oldalon keresi. Ott megint rossz helyen keresi, ezért redirecttel átirányítja a pro címre, és ez így fog menni végig.

HATEOAS-nál a login után megkapja a válaszban a használandó címe(ke)t és egyből a jó címen keresi a felhasználó adatait, majd a barátait is.

Lehet, hogy blr egyik hozzászólásánál van a kulcs a félreértésünknél? "egyszer vissza kell adni, hogy a továbbiakban kivel kommunikáljon" [blr]
Nos, ha egyszer visszaadod és a kliens onnantól azt használja, akkor ez a HATEOAS minimális megvalósítása. Ez jó lesz a pro-s esetben és a geo location-ös helyzetben is; viszont nem ad megoldást a jogosultság kezelésre és a verzió kezelésre.

A fejlesztési órák meg nem feltétlenül nőnek, sőt lehet, hogy éppen csökkennek a használatával.

"Ha mar igy van megtervezve"
Pontosan olyan eseteknél, amiknél előre nem lehet (érdemes) tervezni, de később mégis szükség lesz rá, ott nagyon előjöhet az előnye a HATEOAS használatának. Lásd: sima rendszer -> +pro felhasználók -> +geo location

Ha barmi plusz infot le kell kezelni emiatt, amit korabban nem kellett, akkor az fejlesztoi orat novel. Jelen esetben le kell azt kezelni, hogy a szerver innentol nem ad ertelmes valaszokat, hanem csak egy referenciat, ami alapjan ki lehet talalni, hogy a kerdeses adat hol erheto el valojaban. Ez a kliensoldalon fejlesztesi munkaora, de a szerveroldalon is az, hiszen ezt a funkciot meg kell irni pluszban, le kell tesztelni tobb iranybol is, hibakereses, stb, ez mind-mind ido. Ha azonban valamit egy alacsonyabb reteg transzparensen megold, az pontosan 0 fejlesztoi orat jelent. Mivel a HATEOAS nem egy jol definialt protokoll, amit meg lehet oldani alacsony szinten, igy ez nagyon nem lesz transzparens.

Ami a tervezest illeti: igen, de van mas, a HATEOAS-nal sokkal transzparensebb pattern is ezen feladatok megoldasara, raadasul a pro es nempro felhasznalok kiszolgalasat nem is feltetlen jo fizikailag elszeparalni...
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

Félretéve a konkrét esetet, mert én általában véve szólok a redirect ellen, gondold végig:
Van egy androidos telefonom. Be van állítva, hogy minden elkattintott kép automatikusan mentve legyen a Dropboxon. Egy átlag kép 2 MB. Redirect esetén ez kétszer megy fel, vagyis az 1 GB-os havi limitem már 250 képpel elérem 500 helyett. Ez költség. Persze, nálam jelentkezik, nem a fejlesztőnél, de egy üzleti alkalmazásnál egy ilyen megoldás, ha belső fejlesztés, elég gyorsan rájön a management, hogy itt valami nem kóser, ha külső, akkor meg a userek fognak elég gyorsan anyázni.

Konkrét példa: van egy kliensprogramom, amely elég nagy fájlokat töltöget fel felhőbe. Eredetileg ez a már autentikált kapcsolaton szépen feltolta egy instance-be, aztán az szépen felpakolta a storage-ba. Baromi kényelmes, szinte 0 kliensoldali fejlesztés. Csakhogy elég gyorsan eltömi az instance sávszélességét, ezért muszáj volt kliensoldalon megoldani, hogy a szerver a feltöltéshez ad egy temp URL-t, és a kliens oda tölt fel.
Vajon melyik a drágább: Az ennek működéséhez szükséges kliens és szerver oldalon összesen kb. 500 sor kód megírása, tesztelése, vagy hagyom az egészet, és az eredetileg szükséges small instance-et valami 2XL-re növelem, esetleg indítok a smallból 8-10-et, amire redirectelek?

A konkret feladatra a jo megoldas az lett volna, hogy a kliensprogram S3-ra toltoget fel, es a program fele az S3-tol kapott URL-t kozvetiti csak, amivel a webapp azt csinal, amit szeretne.

Mivel mostanaban majdnem minden app loadbalancolt kornyezetbe kerul fel, igy ezeknek az "appra feltoltom kozvetlenul" cuccoknak lassan le is jar az ideje, pontosan az altalad vazolt okok miatt: eltomi az adott instance savszelesseget tokeletesen feleslegesen. Kell egy dedikalt fajltarolo instance, amit megfeleloen bemeretezel erre a feladatra, es oda kell ezeket a cuccokat feltolni.

De az a lenyeg, hogy ez az orszagonkent/felhasznalotipusonkent/szemszinenkent kulon app instance tokeletesen rossz tervezesi modell. Az alkalmazas felepitese teljesen fuggetlen kell az infrastruktura szerkezetetol, mert ugy a legkoltseghatekonyabb uzemeltetni es kezelni a gepeket, ha sok ugyanolyan instance szolgal ki (es itt az ugyanolyan alatt az ugyanolyan appot is ertem).

A geolokacios cuccra is azt mondom egyebkent, hogy nem szabad pl. domain alapjan szeparalni, mert mi van, ha en nemet vagyok, de kinabol jelentkezek fel. Akkor hiaba van kinai szerver, akkor is a nemet szerverre fog feltolteni (ami adott esetben joval-joval lassabb)? Minek? Mi ertelme van ennek igy? Inkabb legyen az, hogy ha a nemet domainre megyek fel, akkor nemet nyelven jon be az app, de a loadbalancer az IP-m alapjan tudja, hogy ezzel egyutt a kinai szerverre kell feltoltenie - ugyanakkor az app ne akarjon az IP-m alapjan kizarolag kinaiul kommunikalni velem, mert esetleg egy kukkot nem tudok kinaiul.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()

"Tehát login után a pro felhasználó az adatait nem a korábbi címen érheti el, hanem pl. a https://pro.example.com/api/{user} címen."

Na, pont erre gondoltam, hogy szerintem így nem szabad tervezni. Jelen esetben szétbontanád a pro/mezei userek autentikációját?
(Szerintem szinte minden ilyen jellegű módosítás valahol valaminek a felesleges duplikációja a háttérben, de várom az ötletet, ahol nem :)

Az autentikáció a fenti példában egy helyen van, az autentikáció után megy majd két helyre.

Duplikáció valóban van, de nem felesleges. A szerver programot duplikálom, teszem két külön szerverre és mindegyik szervert aszerint állítom be, hogy a kívánt céljaimat elérjem, pl. a sima felhasználókat 1mp alatt szolgáljam ki, a pro-kat pedig 0,5mp alatt, a pro oldal rendelkezésre állása 99,9%-os legyen, a simánál elég 95%, ...

Nyilván meg lehet úgy is oldani, hogy egy szerver dobálja szét a kéréseket, de azt hiszem azt nem kell bizonygatni, hogy jobb, ha nincs bottleneck.

Erről eszembe is jutott egy másik példa. A felhasználókat földrajzi elhelyezkedésük alapján irányítom át más szerverekre. Felállítok szervereket mindenfelé a világban és azt használja, ami a legközelebb van a felhasználóhoz. example.hu, example.de, ...

[Szerkesztve]: Ez utóbbira nagyon jó példa a web világából http://google.com. Ha beütöd ezt a címet, akkor átirányít a http://google.hu-ra, de a web oldalon levő címeket is lecseréli google.com-ról google.hu-ra. Gyönyörű példa a HATEOAS-ra :)

Nos, igen ez a geofelosztás már sokkal reálisabb példa, hasonló problémát már nekem is kellett feloldanom, de az egyszer válaszban adok egy hostnevet és a minden válasz minden objektumához teljes URL-t adok azért nem ugyanaz.

Az természetes, hogy elosztott rendszernél ne egy reverse proxy mögött üljön minden, és ilyenkor egyszer vissza kell adni, hogy a továbbiakban kivel kommunikáljon, de azt még mindig nem hiszem, hogy tudnék hirtelen olyan alkalmazást, ahol szükség lehet arra, hogy a szerveroldali API-t úgy változtassam, hogy a kliens megvalósításához nem nyúlhatok.
(Pont most kell egy szerveroldali API-t nulláról újraírnom [felhőbe költözés], de nem is áll szándékomban a régi klienst használni a jövőben. Ha a fenti metodikával éltem volna eredetileg, akkor sem tudnám megoldani, hogy a régi kliens az új rendszerrel működjön, hacsak nem hagyom a helyén az eredeti implementációt is. Ennek meg sok értelmét nem látom.)

A geofelosztasnak van ertelme, de a pro-nempro felosztasnak nincs. A gyakorlatban olcsobb mindenkit kozel azonos sebesseggel kiszolgalni, mert egysegesebb infrat feltetelez.
--
Ki oda vágyik, hol száll a galamb, elszalasztja a kincset itt alant: 


()=() 
('Y') Blog | @hron84
C . C Üzemeltető macik
()_()