Chrome, AJAX, REST … spravny krok?
Prave koukam na novy prohlizec Google Chrome. Podle Google se vyvoj prohlizecu zastavil a je treba zacit pracovat na novem konceptu, ktery bude odpovidat soucasnym pozadavkum uzivatelu. Rikam si, proc ne? Do toho se mi ale vtira otazka, proc je tu porad snaha napasovat nove napady a nove aplikace (napr. Chrome) nebo nove technologie (AJAX, REST) na stary protokol HTTP a proc se HTTP stale cim dal vic pouziva k jinemu ucelu, nez ke kteremu byl puvodne stvoren. Proc nezacit takrikajic od piky, kili od noveho protokolu, ktery by umoznil snadny a rychly vyvoj internetovych aplikaci a dal jim jednoduche a ucelne rozhrani. Mozna uz je to proste jen takovy standard, pres ktery se jit neda. Mozna je to skoda. Asi jsem proste jenom neprisel na chut aplikacim napsanym v javascriptu, ktere jsou zalozeny na dynamickem obsahu internetovych stranek, asi mi porad unika treba vyhoda RESTu, ktery chapu spis jako takovy ‘workaround’ pro pouziti starickeho HTTP. No, uvidime 
September 3rd, 2008 at 7:55 am
Co je tohle za dis?
REST neni zadny workaround, ale architektonicky styl.Neni vazan na http, ani nejak nevidim, cim by REST nejak http zneuzival. Naopak, http je pro REST idealni protokol.
Co bys rad videl v nastupci http?
September 3rd, 2008 at 9:17 am
To neni zadnej dis na REST ale na uzivani HTTP na veci pro ktery nebylo stvoreno. Ani jsem nepsal zneuzival, ale vyuzival. A proc bych mel pouzivat HTTP a kopirovat jeho chovani pro volani remotnich sluzeb? Jenom proto, ze je to zabehnutej model chovani na netu? Tak treba jsem puvod RESTu spatne pochopil, ale mel jsem za to, ze uziti method HTTP (get, post, put, delete) v RESTu je zamerne, resp. ze se jedna o jejich kopirovani, aby se HTTP dalo pouzit jako protokol, a tohle me nuti na REST pohlizet jenom jako na workaround a nic vic. A co bych rad videl v nastupci HTTP? Treba udrzeni stavu :-p, ktery se musi resit v kazdem front-endovem frameworku jenom proto, ze HTTP komunikace je bezstavova. A treba at tu stare dobre HTTP je a at se pouziva dal k zobrazovani internetovych stranek a internetovy stranky at jsou dal strankami. Nelibi se mi aplikace napsane pomoci html a javascriptu, protoze ani jeden z techto jazyku nebyl za timto ucelem stvoren a nevim proc pouzivat prohlizec jako prostredi pro spousteni aplikaci ala word nebo excel. Proc tu treba neni misto prohlizece, ktery by slouzil k prohlizeni internetovych stranek, nejaky runtime, ktery by umel natahnout z netu aplikaci, ktera by nebyla napsana pomoci html, ale jineho jazyku, ktery by byl komfortnejsi ke tvorbe GUI, komunikaci se serverem apod. Mozna tu byl pokus u Java Web Start, ale to byla spis forma distribuce nez runtime pro webove aplikace.
September 3rd, 2008 at 11:04 am
Ano, REST si vzal zakladni operace z HTTP, ale neni na http vazan. A urcite to nebylo proto, aby se http dalo pouzit primo pro invokaci
vzdalenych sluzeb, ale z duvodu peknych vlastnosti jako je treba moznost cachovani (plynouci prave z bezestavovosti), adresovatelnost ci
uniformni interface.
Jak by sis predstavoval drzeni stavu jinak nez v lokalnim ulozisti ala cookies?
September 3rd, 2008 at 11:23 am
Ja prece netvrdim, ze je na http vazan, ale ze jim byl inspirovan a nemyslim si, ze by to byl zrovna nejlepsi vzor pro rozhrani vzdalenych sluzeb, treba prave uz pro tu bezstavovost, kterou vidim jako nevyhodu. Proc tu mame omrdesat frontendovych frameworku, ktery se predhanej v tom, jakym zpusobem spravuji stav klienta, jakym zpusobem pristupuji k ruznym kontextum apod.? Protoze furt ve finale pracuji na HTTP a ten jim tyhle moznosti nedava a vyvojari je ocividne chtej. Proto tu vznikaj frameworky jako jsou echo, wicket apod. Aby odstinily vyvojare od toho, ze klient pristupuje na server pres HTTP a aby nemuseli sestavovat gui pomoci html, ale regulerniho jazyka apod (to uz ale micham jabka a hrusky). Tim, ze jsem psal o drzeni stavu, tim jsem nemyslel, jakym zpusobem si klient drzi svuj stav lokalne (to uz navic celkem zajimave resi HTML5), ale jakym zpusobem serverova cast vi o tom, s jakym klientem si zrovna povida. A soucasny reseni, kdyz klient neustale posila cookie se svym ID nebo do http requestu pripojuje svoje ID je prave taky takovy workaround pramenici z bezstavovosti HTTP. Verim, ze i jinaci rozhrani by mohlo mit onu zminovanou adresovatelnost a byt uniformni.
September 3rd, 2008 at 11:34 am
REST stav klienta na serveru neresi, vse jde v requestu na resource.
September 3rd, 2008 at 12:41 pm
Jasne, ze jo … copak tvrdim, ze to REST resi … ? Vzdyt rikam, ze prave ta bezstavovost mi treba vadi. Jasne, da se s tim zit, ale ptal jsi se, co bych videl rad v nastupci HTTP. Navic nerikam, ze se musi jednat vylozene o nastupce … http jako takovy mi prijde jako protokol pro aplikace spatny. Zarazilo me jen, proc je tu porad trend stavet aplikace na technologiich jako http, html, javascript a nevznika za timto ucelem vhodnejsi komunikacni protokol a jazyk.
September 3rd, 2008 at 12:48 pm
Jasne, netvrdis to. Jen rikas, ze to tve frameworky resi. Na to ti rikam, ze je hezky REST a jeho inspirace v http, kde se to resit inherentne nemusi. To je jen reakce na tvoji potrebu stavoveho http.
Proc se to stavi na http? Protoze je to celkem jednoduchy protokol s klientem v kazdem jazyce, podporovany nejrozsirenejsimi klientskymi aplikacemi - browsery. A i kdyz je to tak jednoduchy, dodnes browsery nepodporuji napr. PUT. A ted si predstav, ze prijdes s nejakym super protokolem. Jak dlouho bude trvat implementace a adopce. Vsak jsme to videli ve WS-* svete. Specifikace skoro na vsechno a nikdo se nakonec s nikym nedomluvil.
September 3rd, 2008 at 1:48 pm
Tak prinejmensim se to resi tak, ze vse jde v requestu na resource, jak sam pises, a v tom ja vidim uz ten workaround. Jak by si resil treba takovy wizard? Mne nevadi http jako takovy, ale soucasny trend webovych aplikaci bezicich v browserech a postavenych na technologiich, ktere vznikly za jinym ucelem. A s tim jsem zminil i pouziti http jako protokolu pro volani vzdalenych sluzeb. Zde proste vidim, ze vitezi kvantita nad kvalitou, a kdyz jsem videl, ze google chce delat revoluci a posunout prohlizec o neco dal, tak jsem si rek, jestli to nebude zase dalsi drbani se levou rukou za pravym uchem a jestli by se nemelo jit jeste o uroven niz a nebo to je uz ten prah, pres ktery se nesmi.
September 4th, 2008 at 1:53 pm
Jiri, ale ved flash je tu uz dost dlho. A co taky silverlight, Adobe air, Flex, JavaFX. Asi tu bud nejake dovody preco sa zatial nechytaju na html a javascript !?
September 4th, 2008 at 3:17 pm
Njn, … a pak taky java applet. Ale porad je to snaha o spousteni aplikaci v internetovem prohlizeci. Prijde mi to, jako hrat hry na displeji digitalniho fotaku.
September 5th, 2008 at 10:13 am
Jasne, takze tobe celou tu dobu slo o klasickyho tlustyho klienta.
September 5th, 2008 at 1:35 pm
Ach jo … tlusty klient je neco jineho. viz. http://en.wikipedia.org/wiki/Fat_client. Btw. jak je to teda s tim wizardem v restu, kde neresis stav?
September 5th, 2008 at 2:15 pm
No moc tady neachjojuj.
S tim wizardem - REST neni urcite na vsechno. Ale wizard neni tezkej - je to jen dalsi resource. GET s ID vrati tvuj wizard s tvymi daty, POST vytvori wizard, PUT updatuje tvuj wizard. DELETE ho muze smazat pri expiraci session nebo nejakym sweap mechanismem na serveru. Submit na formu muze byt pak POST na algoritmicky resource, ktery dostane URI na wizard a pouzije dana data.
September 5th, 2008 at 2:26 pm
Pokud je wizard resource, znamena to, ze pri kazdym kroku si posilas vsechno?
September 5th, 2008 at 2:33 pm
Tak to zalezi, jak to potrebujes. Resource ma svoji reprezentaci, kterou si ridi klient. Pokud si to tak napises, muzes si pri GETu ze serveru dostat treba jen cast resourcu.
Ano, pri PUTu bys mel posilat vsechna data. Pokud mas komplexnejsi wizard, tak neni problem udelat subresource (/wizard/1/page) pro jednotlive stranky a posilat si jen ty.