XMLHttpRequest - POST a GET - je nějaký rozdíl?

joe:
„V případě GET se parametry objeví (tzn. například vyhledávací políčko je dobré přes GET, abysme případně mohli někomu URL poslat a on se dostal na stejný výsledek)“
No ale ako sa ten niekto dostane k tej adrese, ak ten formulár s metódou GET aj tak neodošleš do celého okna, ale ho odošleš AJAXom a to metódou POST? Ak chceš tú adresu nejako sprístupniť aj bez normálneho odoslania, tak to je cez GET jednoduchšie, lebo treba aj tak reťazec adresy vytvárať a dá sa tá adresa jednoducho sprístupniť a to aj po odoslaní a prijatí výsledku - z objektu XHR a server má k dispozícii tú istú adresu.

„Tohle není třeba řešit, dobrý framework to dělá bez mého velkého zásahu.“
Aký a ako?

„Ale při odesílání AJAXem, tedy stornování defaultní akce odešlu XHR. Tzn. adresu nikdy v adresním řádku neuvidím.“
Že ju nevidíš v adresnom riadku, neznamená, že ju nemôžeš využiť inak, napríklad na strane servera, ako spomínala Tori, alebo aj na strane klienta pred alebo aj po odoslaní dát. Adresa pri normálnom odoslaní tiež nemusí byť vždy viditeľná.

TomášK:
„Kdysi jsem zaslechl, že roboti vyyhledávačů zpravidla odesílají jen GET požadavky“
Roboti zpravidla nezkoušejí odesílat jakékoliv formuláře.

_es:
Radíš používat iframe jako jakýsi remote objekt, ze kterého pak případně bude javascript získávat data? Za to bych ti u svého projektu urazil obě ruce.
Pokud je potřeba se serverem komunikovat asynchronně, používá se XMLHttpRequest - ideálně ve svém nativním formátu, tedy XML. Nevím, co se ti na tom pořád nelíbí. Kromě (mnohem) větší rychlosti je tu také lepší kontrola událostí, které při komunikaci vznikají.

joe:
„GET nebo POST? Není to jedno? Nebo k čemu to vlastně je?“
GET je součástí URI, jako url-encoded string. A URI má pochopitelně své limity. U standardně nastaveného Apache jsou to 4 kilobajty. Prohlížeče budou mít limity ještě menší - Explorer tuším 2 kilobajty.
POST má limit taky, ovšem poněkud velkorysejší - u Apache zpravidla omezený jen velikostí paměti, PHP pak standardně 8 megabajtů.

DoubleThink:
„používá se XMLHttpRequest - ideálně ve svém nativním formátu, tedy XML.“
XML sa práve používa spolu s XHR veľmi málo, lebo je pre zpracovanie pomocou JS zbytočne zložitý a hrozia komplikácie. Používa sa hlavne JSON (získaný z obyčajného textu) alebo len obyčajný text.

„Kromě (mnohem) větší rychlosti je tu také lepší kontrola událostí, které při komunikaci vznikají.“
Napríklad JSONP, ktorého princíp je skoro rovnaký, je veľmi rýchly, takže z hľadiska rýchlosti to bude úplne opačne - ak sa to spraví správne. Ja som tu nikde neradil nepoužívať XHR, len ho nepoužívať namiesto normálneho odoslania formulárov - na to určený nie je.

Reaguji na joa:
Rozdíly mezi GETem a POSTem jsou u XHR totožné jako u formulářů:
1) Fakt, že u GETu můžeš adresu vidět (snadno či nesnadno), jinými slovy znamená, že jde na dotyčný zdroj odkázat. Na výsledek POSTu odkázat nejde.
2) Explorer dovoluje jen 2 kB dlouhou adresu, Mozilla má limit tuším 64 kB, ale vždy tam nějaký limit je. Data zaslaná metodou POST limit nemají (alespoň na straně klienta).
3) Obecně platí, že POST by měl aktivně způsobit nějakou postřehnutelnou změnu, zatímco GET by měl jen pasivně vybírat obsah a uživatel by ho mohl vybrat tisíckrát po sobě, aniž by tím cokoliv změnil.
4) Při POSTu se cílová stránka nikdy nebere z keše. Pokud programátor (správně) vnímá keš jako přítele, ví, kdy zvolit GET.

„Mj. POST není nijak bezpečnější jak GET. Jen skrývá parametry z URL, nic víc.“
Ty parametry se díky tomu nekešují a neukládají se do logů a do externích statistik a neposílají se v refereru při odchodu na cizí stránku. Takže bezpečnější je. Při posílání skrze XHR část rizik u GETu odpadá, ale ne všechna.

„Výhody použití AJAXu například v diskusi při posílání příspěvku“
To je všechno v podstatě jen jedna výhoda a je platná pro jakékoliv zpracování formuláře JavaScriptem, nikoliv exkluzivně pro XMLHttpRequest. Nedávno jsem třeba v praxi použil 204 No Content — dojde-li k chybě, uživatel přejde na jinou stránku, v opačném případě zůstává na místě a o uzpůsobení zobrazení se postará JS, aniž by dostal od serveru nějaká data (pěkný český článek o tomto triku napsal DoubleThink, škoda, že už není k nalezení). Tento postup sice nejde použít vždycky, ale v tom mém konkrétním případě vidí návštěvník stejné výhody jako u tebe s AJAXem.

Odeslání AJAXem má jednu dosud nezmíněnou nevýhodu, která je pro některé uživatele docela podstatná: Pokud skriptem stornuješ nativní odeslání formuláře, znemožníš tím uložení vyplněných textových <input>ů do našeptávačové historie prohlížeče.

„v tomto to jednodušší je, ale když to jQuery udělá za tebe, neřešíš nic (nebo když na to máš už funkci)“
Ještě jsem neviděl žádnou funkci, která by dokázala formulář poslat skutečně za všech okolností stejně, jako kdyby ho odeslal prohlížeč. Pokud se bavíme o formulářích odesílaných na stejnou doménu na stránkách deklarujících výhradně kódování UTF-8, bez formulářových polí nazvaných action, method a podobně, bez formulářového pole __charset__ a bez uploadů souboru, bude metoda z jQuery nejspíš fungovat stejně jako prohlížeč. Netvrdím, že takových situací není většina, jen poukazuji, že občas nestačí neřešit nic.

„do rámce musím načítat prakticky znovu celou stránku - HTML, HEAD, všechny skripty, které uvnitř použiju, BODY, samotný obsah, ...“
Obalové značky jsou nepovinné a skripty můžou volat top.funkce() místo funkce(). Uznávám, že se skriptováním napříč rámy si občas programátor může užít mnohem víc zábavy, než by chtěl.

„Protože kdybys to neudělal, bez JS by se ti asi pořád odesílal do nějakého rámce, nevím jak by to reagovalo, pokud by neexistoval. Může se to v každém prohlížeči chovat třeba jinak.“
Nehrozí, ve všech prohlížečích by byly důsledky stejně nepříjemné. Atribut target by v případě použití skrytého rámce měl nastavit až JS, třeba v onsubmitu.

„Po odeslání formuláře bys musel přidávat iframe do DOMu, řekl bych, že jeden ti stačit nebude, co když uděláš víc požadavků těsně za sebou - dostaneš jen ten poslední.“
Což může být někdy účel. Řekl bych, že tu s _esem rozebíráte několik odlišných řešení, z nichž jsou různá různě vhodná pro různé situace. Osobně se v praxi snažím každý případ posuzovat individuálně. Někdy se hodí <iframe>, někdy XMLHttpRequest, někdy JSONP, někdy new Image(), někdy 204 No Content, někdy Comet, někdy dokonce behavior: url(#default#download). Zvážit všechna pro a proti a rozhodnout se pro optimální postup bývá složitější, než vybrat si mezi GETem a POSTem.


Reaguji na _es:
„aký iný objekt, okrem formulárov, sa dá použiť na načítanie dát pomocou HTTP metódy GET?“
Třeba <script> :-) (tady jsem se asi trochu ztratil v kontextu)
Škoda, že nejde JSONP použít s POSTem.

> > „Mimochodom, keď už používaš formuláre, u ktorých aj návštevník bez JS očakáva funkčnosť, máš ošetrené, aby to bolo nejako rozumne funkčné aj bez JS?“
> „Tohle není třeba řešit, dobrý framework to dělá bez mého velkého zásahu.“
> Aký a ako?
Tipnul bych si, že framework na straně serveru kouká na speciální HTTP hlavičku dodanou frameworkem na straně klienta a tomu přizpůsobuje odpověď.


Reaguji na TomášeK:
„Kdysi jsem zaslechl, že roboti vyyhledávačů zpravidla odesílají jen GET požadavky, jestli je to pravda, nevím.“
Dává to smysl, protože data, na která nejde odkázat z výsledků vyhledávání, nejsou pro provozovatele vyhledávačů zajímavá.

joe:
Dodám, že POST a GET jsou rozdílné metody a v případě většiny serverových scriptů je nelze zaměnit. Vezmi v potaz například php. Proměnné zaslané pomocí POST jsou v poli $_POST[] a proměnné zaslané pomocí metody GET v poli $_GET[]. Při zaslání dat pomocí druhé metody pak bude serverový script pracovat, jako by nedošlo k odeslání dat žádných.

K vhodnosti použití - část konvencí (tzn. předávání parametrů stránky v adrese pomocí GET, aby bylo možné na stránku odkázat a citlivých dat jako heslo pomocí POST, aby na stránku s odeslaným heslem nebylo možné odkázat / heslo z odkazu přečíst apod.) je samozřejmě u AJAXu irelevantní. Zbytek však platí, tedy maximální délka dotazu - GET omezené a pak samozřejmě fakt, že požadavky klienta, které obsahují POST data, nelze cachovat. Na rozdíl od metody GET není při přenosu dat ovlivněno URL vyžádané webové stránky.

EDIT: Chamurappi tasil kolty první. No vzhledem k tomu jak dlouho se tu o tom joe hádá mu neuškodí přečíst si to dvakrát. :-)

joe:
„Ukládám do cookies :-)“
Cookies nejsou určené k ukládání textových polí ani delších textů, už jen protože mají omezenou velikost. Hlavně je však jejich obsah odesílán při všech HTTP požadavcích serveru, což je s narůstajícím počtem "cookies" pak na době načítání stránek s množstvím obsahu poměrně znát.

„1)... 2)... 3)... 4)...“
Usuzuji, že můj post jsi nečetl. :-)

„protože kouká jen na parametry, které stejně přijdou oběma metodama. “
V tom se mýlíš, cache má výslovně zakázáno rozebírat a porovnávat předchozí data odeslaná metodou POST. Data jsou vždy odeslána a přijata znova, jelikož správný programátor využívá metodu POST k provedení změn na straně serveru. Požadavek tedy vždy musí být odeslán. Mluvíme nyní o cache na straně klienta.

„Řeč je například o filtrovacím formuláři.“
Oprav mě pokud se mýlím, ale Chamurappi mluvil o našeptávačích. Pakliže budeš v cookies skladovat veškeré hodnoty, které input pole kdy mělo, pak nastanou problémy o kterých jsem psal.

Nemyslím, že sem zanáším něco, co sem nepatří. Pleteš se, pokud si myslíš, že jde pouze o tvé téma. Pakliže sem napíšeš, že odrovnávání našeptávačů řešíš pomocí cookies a nějaký nováček, který sem přijde, si to přečte, je problém na světě. :-)

Chamurappi:
> Reaguji na TomášeK:
> „Kdysi jsem zaslechl, že roboti vyyhledávačů zpravidla odesílají jen GET požadavky, jestli je to pravda, nevím.“
> Dává to smysl, protože data, na která nejde odkázat z výsledků vyhledávání, nejsou pro provozovatele vyhledávačů zajímavá.
No iná vec je, ako sa k tomu GET požiadavku vyhľadávač dostane. Ak bude závislý od vyplnenia, či kombinácií hodnôt rôznych formulárových polí, tak asi nehrozí, že by taký formulár vyhľadávač vyplňoval a odosielal. Pochybujem, že vyhľadávač vôbec nejaké formuláre odosiela a indexuje výsledok, no možno sa mýlim.

joe:
„Nevím co bych s tou adresou měl dělat, můžu ji sklidem zahodit, protože mi k ničemu není.“
Môžeš ju ponúknuť návštevníkovi ako odkaz na stránku, ktorý bude funkčný aj bez JS, ak teda tá adresa zodpovedá celej stránke.

joe:
„Nejde mi o skutečné rozdíly GET/POST, ale JEN při použití XHR“
Ale pri všetkých vysvetlených rozdieloch, kde si si pochvaľoval, že si bol konečne pochopený, ti boli vysvetlené práve tie „skutočné“ rozdiely, nezávislé od toho, ako dotaz GET alebo POST vznikol, teda rozdiely na úrovni HTTP protokolu.

joe:
„Myslím, že kdo si chce uložit stránku, ten zkopíruje to, co má v adresním řádku.“
No ale tak si predsa v tvojom prípade skopíruje len odkaz na úvodnú stránku, nie odkaz na ekvivalent zobrazenej stránky.

„už jsi to někde viděl, a že by to někdo používal?“
Napríklad Google mapy.

joe:
„Nicméně hodnoty z takového pole je lepší ukládat na serveru, ať se každému nabídne i to, co hledali ostatní, ne?“
Dozajista. Jak ale v takovém případě zapojit do práce cookies jde mimo mě. :-)

„Jediný rozumný důvod, proč to při XHR posílat stejnou metodou jako je uvedena u formuláře, je způsob čtení na serveru.“
Bylo už tu mnohokrát řečeno, že prohlížeč vůbec nemusí v případě žádosti GET odesílat žádost serveru ale využít data z catche. Máš naprostou pravdu, že tzv. "GET data" v adrese se dají skrýt do hashe a následné načítání dat ze serveru pomocí XHR může být provedeno jak pomocí GET tak POST, PUT, co je lepší volbou bys tedy měl zvažovat na úrovni protokolu, ne adresy, kterou uživatel vidí v prohlížeči. Viz. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Reaguji na joa:
„Já si pod tím v tu dobu představil předvyplnění formuláře. To asi žádný prohlížeč nedělá.“
No vidíš, to mě nenapadlo, že nativní našeptávače souvisejí i s převyplňováním zapamatovaných políček. Pokud skriptem stornuješ odeslání údajů, jak se prohlížeč dozví, že by se měl zeptat, jestli si je má zapamatovat?

„Nicméně hodnoty z takového pole je lepší ukládat na serveru, ať se každému nabídne i to, co hledali ostatní, ne?“
My se bavíme jen o hledání? Co když chci, aby si to zapamatovalo telefon, abych ho nemusel na jiné stránce s name="telefon" vypisovat?
To je pořád ta samá zúžená perspektiva, představuješ si vždy pouze jedno své konkrétní použití. Ve stejném duchu se táhne celé vlákno — ptáš se obecně, dostáváš obecné odpovědi a každému pak vynadáš, protože ta ultimátní pravda „AJAX POST je boží!“ není v řadě situací ani ultimátní, ani pravda :-)

„Pokud na první straně chceš zobrazit nejnovější data, k čemu ti pak asi bude cache?“
My se bavíme jen o první straně s nejnovějšími daty? Jasně, že někdy je kešování nežádoucí (to tu kupodivu všichni dobře víme). Tam, kde nežádoucí není, se rozhodně hodí metoda GET.

> „3) Obecně platí, že POST by měl aktivně způsobit nějakou postřehnutelnou změnu…“
> O tomhle se nebavím, nepatří to sem :-)
Patří, protože z této zvyklosti mohou vyplývat další drobné nuance. Lze třeba předpokládat, že data zaslaná metodou POST jsou cennější — a myslím, že tento předpoklad je zanesený v hloubi digitální duše serverů. Možná je to jen můj dojem, ale řekl bych, že při přetížení tato diskuse zahazuje GETy mnohem ochotněji než POSTy — pokud v krizovém období jen listuji, dostávám okamžitě hlášku o přetížení, kdežto pokud pošlu příspěvek, server se minutu potí a pak mi vítězně pošle stránku bez stylů i obrázků. Dává to trochu smysl, ne? Kdybys programoval webový server, neuvažoval bys podobně? Nevěnoval bys POSTům větší péči než GETům?

Jakou že máš vlastně motivaci k tomu, abys GET a POST nerozlišoval? Stačí jen dosadit jeden řetězec na jedno místo, ne?

joe:
„v případě AJAXu se to dává za # v URL. Nastavuje se tedy v JS hashString, právě z toho důvodu, aby se adresa dala zkopírovat.“
No ale časť v URL za # sa serveru neposiela, takže bez zapnutého JS to bude na nič. Môžeš si sám vyskúšať, že odkaz Seznamu je bez JS nefunkčný a odkaz Google funkčný. Aj pri zapnutom JS je načítanie takého odkazu-neodkazu zložitejšie, musí JS modifikovať už načítanú (načítavanú) stránku.

joe:
Požadavky POST kladou větší nároky na zpracování než požadavky GET. Co se výkonnosti týče, mohou být požadavky GET až dvakrát rychlejší než požadavky POST odesílající stejné množství dat.

Tím neříkám, že místo požadavků POST používat vždy požadavky GET, samozřejmě záleží na objemu dat, která ještě metoda GET bezpečně zvládne, nebo co už je třeba odeslat prostřednictvím metody POST.