Souboj POST VS GET (diskuse)

[finc]

V podstate souhlas. Problem ovsem muze nastat u nekterych webovych frameworku. Napriklad takove JSF (Java), je komponentovy framework, ktery serializuje viewstate vzdy u klienta a pri novem requestu jej potrebuje pro zregenerovani komponent. Z tohoto duvodu je v JSF kazda druha ptakovina odesilana POSTem. Mam pocit, ze ASP je na tom v nekterych pripadech podobne.

Jinak rozdeleni, co se ma odeslat pomoci GET a co pomoci POST je spise otazkou praxe. Pote jiz nepremyslite, co zvolit, ale vite presne co zvolit :)

[Toman]

Ano, v zápise to možná bylo pojato až zbytečně obecně, ale konkrétní příklad, který jsem uvedl - filtrování - mi nepřijde jako šťastné, když je odesláno POSTem. Ale jak říkáte - praxe je praxe, pak jdou pravidla stranou, s tím plně souhlasím.

[CEST]

IMHO je obecne nejlepsi POSTy hned po prevedeni cinnosti presmerovat na novej GET request. Tak potom reload nepacha nic spatnyho. Pak si muze klidne formulare posilat POSTem, kdyz ale nakonec skonci na GETu s tim, ze ty data cte ze session, neni to zadnej problem.

Taky neni obvykle moc hezky, kdyz je URL dlouhy jak svine se spoustou ruznyho bordelu. Tam se pak hodi POST i pro odesilani filtru pro cteni dat z DB.

[Toman]

Přesně, pokud je někde POST, je nejlepší po zpracování POSTu udělat REDIRECT.

[rou7]

+1

[mkoubik]

Taky neni obvykle moc hezky, kdyz je URL dlouhy jak svine se spoustou ruznyho bordelu. Tam se pak hodi POST i pro odesilani filtru pro cteni dat z DB.

Tam samozřejmě nemá POST co dělat a ten "bordel" je v adrese proto, abys mohl někomu poslat odkaz, nebo si ho uložit do záložek a nastavení se uchovalo. Tohle uvažování (dělá to bordel v adrese, tak tam frknu POST) je přesně příklad toho, proti čemu se zápisek ohrazuje.

[Non_E]

Právě u filtrování má smysl odesílat data postem. Nejen že si člověk zachová jednoduchou url, ale hlavně zabrání přetečení url v IE (v6?). Uchovávat data o filtraci v GET může být i chyba, pokud nemají všichni návštěvníci přístup ke stejným datům, a budou si adresy posílat.

Optimální řešení, co se pamatuju, je odeslat formulář metodou POST a v odpovědi říct prohlížeči 303 See Other. Vyhnete se tak opakovanému odeslání formuláře, přetečení url a zachováte url hezkou (jestli doteď byla).

[mkoubik]

Ale u filtrování není "opětovné odeslání formuláře" (jestli takhle říkáš opětovnému get požadavku na ?q=neco&sort=neco) vůbec problém, protože nemění stav serveru. Naopak jinak to udělat ani nejde (kromě toho postu, který ale dělá to samé, nebo uložení v session, které je nahovno).

[Toman]

Proč myslíš, že session je na hovno, když to chceš někde mít uložené po celou dobu sezení - práce se systémem. Jak bys to řešil jinak?

[mkoubik]

Myslim pro ukládání vyhledávaného výrazu a filtrační options. Pokud požadavek nemění stav serveru, tak by měl vrátit pokaždé stejnou stránku (pokud se nezmění data na serveru apod.). Koukni se na google.com/search - víš prd, co jsem hledal (pokud by to bylo v session).

[Toman]

No, to máš pravdu - ale já měl na mysli, třeba: máš několik výrobků, a chceš vypsat pouze o jednoho výrobce, takže si ho vybereš v selectu, a odešleš tlačítkem, to se odešle GETem a uloží do SESSION - tím se vlastně vždy při návratu na danou stránku nastaví filtr tak, jak byl nastaven naposledy - než vyprší SESSION.

[Filip Jirsák]

Pak si otevřete druhou záložku pro jiného výrobce, vrátíte se na první a kliknete na odkaz „další“, a očekáváte dalších 10 výrobků od prvního výrobce – a mezitím vám tam naskočí dalších 10 výrobků od druhého výrobce, protože druhá záložka přepsala údaje v session.

[Non_E]

To je vada na kráse, předávat všechny informace v url také nejde. Řešením by mohlo být předání session ID, to se mi ale vůbec nelíbí.

Podobná situace ale nastane například i tehdy, když se někdo v druhém tabu pokusí přihlásit pod jiným účtem.

[Filip Jirsák]

Proč by to nešlo předávat v URL? Pokud jsem na seznamu výrobků od jednoho výrobce, je přirozené, že ta stránka bude mít adresu /vyrobci/vyrobce-X. Zkuste na chvíli zapomenout na databáze a dynamické generování stránek a představit si, že web generujete jednorázově do statických stránek – myslím, že hned budete vědět, jak by vypadala jednotlivá URL.

[Non_E]

Proti předávání parametrů v url jsem v tomto konkrétním případě proto, že těch parametrů může být pěkná spousta. Setkal jsem se s tím, že původní návrh se udělal podobnějak píšete /vyrobci/vyrobce-X. Časem přibývali dodavatelé (a další možnosti hledání) a nakonec vše skončilo u IE tím, že URl byla delší než 2083 znaků.

[Filip Jirsák]

Pan nezbývá než v UR nechat jen ty podstatné parametry a zbytek uložit do session, přičemž ale sessionID bude v URL.

[Non_E]

Ve výsledku stejně nemůže zákazník poslat URL kolegovi/kamarádovi, protože by mu dal své session ID. To ale neví a klidně to udělá; tím okamžikem máme horší problém, objednávky chodí špatné osobě atd. V nejlepším případě vynechá své sessionID a druhá strana dostane možná podobný výsledek, ale možná úplně jiný.

Na záložky (bookmarks, oblíbené…) také nemůže spoléhat, protože o session může přes víkend přijít (navíc pravidelná změna sessionID zvyšuje bezpečnost).

[Toman]

Tak jak efektivně řešit?

[Non_E]

Vyber si jedno nebo druhé řešení a smiř se s omezeními.

[Filip Jirsák]

SessionID s údaji o přihlášeném uživateli nemusí být shodné se sessionID s údaji o aktivním filtru. Jak jsem psal, podstatné parametry by měly být v URL, takže by druhá strana neměla dostat podstatně odlišný výsledek. Pokud vás opravdu trápí délka URL, nemusíte tam dávat popisné názvy, stačí jen kódy – a pak můžete do URL schovat celkem hodně.

[Non_E]

Data poslaná metodou POST se samozřejmě zpracují a uloží do session. Proč? Například když mám katalog zboží (e-shop), tak si nechci přeci pokaždé klikat na formulář, aby se produkty řadily v kategorii podle ceny. Nebudu ani ke každému odkazu připisovat parametry, které by se na odkazované stránce mohly hodit.

[mkoubik]

Jinak s prvním odstavcem samozřejmě souhlas.

[Kvakor]

Pokud si to ještě pamatuju z RFC, tak zatímco u GET se předpokládá, že se pro každé jednotlivé URL stav nebude měnit (a tudíž se může cachovat), u POSTu se naopak počítá, že se stav měnit bude a tudiž se cachovat nesmí. U GETu se navíc ještě předpokládá že je idempotentní, tj. že jeho opakované použití by mělo vrátit stejný výsledek nezávisle na tom, kolikrát proběhlo opakování.

V praxi se bohužel na uvedené zásady kašle

[xxx]

Ja myslim, ze ten problem je, ze jaksi tvurci HTTP nepredpokladali, ze lidi do nej budou chtit balit vsechna ta hejblatka, blikatka a jine interaktvni kokotiny co se dnes na webu objevuji.

BTW: jak je myslena ta idempotence. To jako, ze si treba muzu vybrat zobrazit data za poslednich 5/10/15 minut. Je to idmepotentni, protoze furt dostanu data za stejny casovy interval, nebo to neni idempotentni, protoze ty data samotna jsou jina? Pokud to je druha moznost, tak si nedokazu predstavit jaka data by to mohla splnovat.

[Kvakor]

K té idempotenci - pokud si to dobře pamatuju, jde hlavně o to, že u GETu by nemělo vadit, jestli najednou dorazil jeden nebo třeba pět GET požadavků, vrácená data by měla být stejná. Např. pokud uživatel ztratí trpělivost a několikrát máčkne na Reload, měl by dostat stejná data, jako kdyby na Reload nemačkal a vyčkal času jako husa klasu.

Jinak řečeno, nejde o to, jak se data mění během času (to má na starosti cachování a nastavování platnosti stránky), ale jestli záleží na počtu volání požadavků při vrácení výsledku.

[loketnik]

Naprosty souhlas. Nekteri radoby vyvojari obcas vymysleji absolutni harakiri a hlavne uplne zbytecne v tomto pripade.

[Luboš Doležel (Doli)]

V tomhle jsou úžasné weby dělané v ASP.NET, kde vývojář všude nacpe javascript:__doPostBack()...

[miho]

Nikoliv, vývojář nic takového nedělá a často ani neví, jak to uvnitř funguje. To vygeneruje .net sám za běhu. Vývojář jen z toolbaru přetáhne nejakou komponentu do webové stránky, případně u ní nastaví vlastnost autoPostBack, dvakrat na ní klikne, otevře se mu editor s připravenou kostrou metody, ktera danou událost obslouží

[mkoubik]

Tohle je obecně bolest komponentových frameworků, ať už je to .NET, JSF, nebo PHP4Applications. Prostě pokoušet se naroubovat postupy z tvorby GUI aplikací na bezstavový HTTP je jeden z hlubokých přešlapů lidstva, na který, když ne my, tak příští generace určitě krvavě doplatí.

[dark]

Ale ty aplikace se pak tvoří rychleji. Já osobně si v js dokážu napsat cokoliv, ale nedivím se lidem, co v js psát nechcou a raději použijou komponentní frameworky, např asp.net nebo wicket.

[mkoubik]

Věř mi, že existují nekomponentové frameworky, ve kterých se tvoří aplikace rychleji. Např v Nette nejsou klasické postbackové komponenty (jak říká DG "pravoúhlé oblasti stránky"), ale pouze autonomní čási aplikace, které si uchovávají stav aplikace na serveru a ne v hidden polích a dají se (různými způsoby) vypsat (i vícekrát) na stránku.

Při kliknutí na odkaz (s vypnutým javascriptem - tzn href=) ti vrátí stránku s aktuálním stavem všech komponent, pokud máš zapnutý ajax a povolený javascript (tzn. onclick), tak se vrátí json objekt s obsahem změněných komponent a ty se překreslí javascriptem. Ajax nikdy nebyl jednodušší (v podstatě $presenter->isAjax=true;) a přístupnější (Žádný prasárny typu <a href="javascript:..." nebo <a href="#" onclick="..."). Pokud máš vypnutý javascript, nebo klikneš prostředním tlačítkem ve firefoxu, tak se ti otevře stejná stránka jako by byl výsledek ajaxu, akorát s refreshem.

Změny stavu se provádí jednoduchým getem, ve kterém je jenom změnění proměnná (následně refresh), nebo pomocí post-redirect-get (podle účelu), vybrané proměnné si můžeš vytáhnout do url.

[dark]

Tak funguje ale hodně frameworků, v prvé řadě jde o to, kdo s tím dělá, a jaké má znalosti. Já osobně PHP nepoužívám, a doufám, že už nikdy nebudu muset