<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div>Ahoj,<br><br></div>Petr byl rychlejší. Rozdíl mezi GET, PUT, POST, atd. je v tom, že je přesně ve specifikaci řečeno, co může nebo nemůže způsobit, např. opakovaným zavoláním.<br><br>> HTTP REST uz je striktnejsi a popisuje presnejsi pouziti i DELETE, PUT, PATCH, etc. <br><br></div>To není úplně přesné. HTTP je protokol a má svoje specifikace. REST je nějaký styl architektury aplikace, se slovesy v HTTP nemá až tak moc společného a nemusíme jej tady asi ani řešit (jo, vím že jsem to sám dřív taky motal do sebe). Úplně pro tento případ postačí, pokud se budeme držet toho, co nám radí (či specifikací přikazuje?) HTTP samotné.<br><br></div>Jsou na to v zásadě dvě RFC:<br><br></div>- základ v <a href="https://tools.ietf.org/html/rfc7231">https://tools.ietf.org/html/rfc7231</a><br></div>- PATCH dodělaný a dolepený v <a href="http://tools.ietf.org/html/rfc5789">http://tools.ietf.org/html/rfc5789</a><br><br></div>Nebát se číst specifikaci! Je to lidsky psané. Tady přesně se mluví o tom, jaký je rozdíl mezi metodami, co jaká znamená a co přináší jejich použití a je tam i pěkná tabulka: <a href="https://tools.ietf.org/html/rfc7231#section-4.1">https://tools.ietf.org/html/rfc7231#section-4.1</a><br><br></div>GET je jen čtení, akce, která neublíží. Když budeš při GET mazat, projede ti odkazy Google nebo kdokoliv jiný a smaže ti cokoliv co tam zrovna mažeš. Tzn. vše podle specifikace předpokládá, že GET by neměl nic měnit. Taky to znamená, že cokoliv co je GET se může kdekoliv po cestě kešovat.<br><br>PUT je nějaká změna, která je tzv. idempotentní, tzn. když ji pošleš několikrát za sebou, tak se pak už nic nezmění. Typicky když něco nastavíš na "vypnuto", tak stejný request můžeš poslat třeba tisíckrát po sobě a ta věc bude mít nakonec stále "vypnuto". Abych dal protipříklad, nehodí se to na věci, které jsou např. "přepni" ve stylu vypínače na světlo - když ho pošlu jednou tak vypne, podruhé zapne, atd. Aby to mělo danou vlastnost, implementace PUTu vypadá tak, že sestrojíš celou novou reprezentaci a tou "přeplácneš" tu starou. Takový "replace". Když v cíli nic není, tak se to při PUTu na dané URL vytvoří, tzn. vhodné i pro vytváření, pokud víš "ID" předem.<br><br></div>DELETE maže, následně by po něm nemělo nic zůstat.<br><br></div><div>PATCH je speciál na částečné změny, tzn. že pošleš nějaký diff, kterým řekneš co se má změnit a server to podle toho diffu nějak změní. Záruky neveliké, všelijaké, a tak dále.<br></div><div><br></div>POST je nějaká změna, která ale nemusí být nutně idempotentní. Je to základní způsob, jak udělat změnu stavu na serveru. Nedá se to kešovat a tak dále.<br><br></div>Pozn.: HTML formát a klienti kolem něj (typicky prohlížeče atd.) podporují často jen GET a POST. S tím si vystačí, protože to hlavní co je potřeba rozlišit je kešovat/nekešovat a bezpečné/nebezpečné. POST má myslím ve specifikaci někde taková "zadní vrátka", že kromě toho, že je určen k tomu co jsem napsal výše, tak může být použit i na "cokoliv jiného". V důsledku je tedy i HTML s formulářem na mazání osedílaným přes POST udělán správně podle HTTP specifikace. Klidně můžeš udělat všechno přes POST a bude to jakože správně, ale tím se připravuješ o to, že GET je pro čtení efektivnější. Udělat ale všechno v GET místo POST je špatně a koleduješ si, protože označuješ "nebezpečné" akce jako "bezpečné" (stejně tak s kešovatelností).<br><br></div><div>Sorry že jsem se tak rozepsal. Hlavně mi moc nevěřte a přečtěte si to raději v té specifikaci. Já jsem taky jenom člověk, ale tam je to prostě vysvětlené a napsané, tak jak to má být.<br><br></div>Honza<br><div><div><div><div><div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-09-16 9:37 GMT+02:00 Petr Viktorin <span dir="ltr"><<a href="mailto:encukou@gmail.com" target="_blank">encukou@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2015-09-16 7:45 GMT+02:00 Petr Blahos <<a href="mailto:petrblahos@gmail.com">petrblahos@gmail.com</a>>:<br>
> Ještě poznámečka: Pokud bude GET měnit vnitřní stav aplikace, a povede k<br>
> němu<br>
> nějaký link, tak ho Google klidně navštíví při indexování :-) Nebo jak měl<br>
> kdysi takové<br>
> to přednačítání odkazů...<br>
<br>
</span>Je psáno [1], že GET nemá měnit stav, a spousta nástrojů to předpokládá.<br>
Kromě robotů to předpokládají třeba různé keše nebo load balancery. Ty<br>
sice teď asi nepoužíváš, ale neměl bys zapomenout na to, že *učíš*<br>
lidi používat HTTP. Nauč je to prosím správně.<br>
<br>
[1] ve specifikaci HTTP: <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html" rel="noreferrer" target="_blank">http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html</a><br>
> the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".<br>
<div class="HOEnZb"><div class="h5"><br>
> 2015-09-15 22:33 GMT+02:00 Ales Zoulek <<a href="mailto:ales.zoulek@gmail.com">ales.zoulek@gmail.com</a>>:<br>
>><br>
>> Technicky rozdil mezi PUT a GET je minimalni. Je ale konvence, aby akce<br>
>> odpovidala tomu HTTP "slovesu".<br>
>><br>
>> Uplnym minimem je rozliseni mezi GET a POST. Tzn. GET (narozdil od POST)<br>
>> by nemel menit vnitrni stav serveru, pouze ten stav cist.<br>
>><br>
>> HTTP REST uz je striktnejsi a popisuje presnejsi pouziti i DELETE, PUT,<br>
>> PATCH, etc.<br>
>><br>
>> Pokud nemas vylozene duvod to nedodrzovat, tak je lepsi se te konvence<br>
>> drzet.<br>
>><br>
>><br>
>> A.<br>
>><br>
>> On Tue, Sep 15, 2015 at 9:54 PM Marek Nožka <<a href="mailto:marek@tlapicka.net">marek@tlapicka.net</a>> wrote:<br>
>>><br>
>>> Ahoj<br>
>>><br>
>>> On Tue, 15 Sep 2015 08:40:33 +0200 Honza Javorek <<a href="mailto:mail@honzajavorek.cz">mail@honzajavorek.cz</a>><br>
>>> wrote to Konference PyCZ <<a href="mailto:python@py.cz">python@py.cz</a>>:<br>
>>><br>
>>> > Jestli mají posílat nějaké informace a těma měnit stav na serveru, tak<br>
>>> > musíš použít i něco jiného než GET, pokud se budeme bavit aspoň o<br>
>>> > samotném<br>
>>> > blbém HTTP, když už ne o RESTu.<br>
>>><br>
>>> To je právě to, co nechápu. Pokud vezmu množinu jednoduchých akcí jaký je<br>
>>> rozdíl mezi<br>
>>><br>
>>> GET /123acb/krok<br>
>>><br>
>>> a mezi<br>
>>><br>
>>> PUT<br>
>>> id = "123abc",<br>
>>> akce = "krok"<br>
>>><br>
>>> Chápu, že když chci poslat nějaký větší objem dat je PUT jistě lepší, ale<br>
>>> pokud jde jen o jednoduché povely, co mi PUT nebo DELETE přináší za<br>
>>> výhodu?<br>
>>><br>
>>> > Já bych ti to klidně nějak zkusil namodelovat, ale k tomu by se hodila<br>
>>> > komplet pravidla té hry a možné stavy, do jakých se lze dostat a jak se<br>
>>> > do<br>
>>> > nich lze dostat.<br>
>>><br>
>>> Pravidla jsou zatím velice jednoduchá:<br>
>>> Server umístí hráče na hrací pole a ukáže jim, kde je poklad. V každém<br>
>>> kole<br>
>>> lze provést jednu z akcí:<br>
>>>   * otoč se o 90° doleva<br>
>>>   * otoč se o 90° doprava<br>
>>>   * udělej krok<br>
>>><br>
>>> Cílem je, za co nejmenší počet kol dosáhnout cíle. Server upozorní pokud<br>
>>> by klient šel do zdi nebo pokud chtějí dva hráči vejít na stejné políčko.<br>
>>> Počítám, ale časem s rozšířením pravidel o časované bomby, střílení,<br>
>>> dobíjení<br>
>>> a vybíjení baterií, práce v týmu. Uvidíme jak nám to půjde.<br>
>>><br>
>>> Díky<br>
>>>       Marek<br>
_______________________________________________<br>
Python mailing list<br>
<a href="mailto:python@py.cz">python@py.cz</a><br>
<a href="http://www.py.cz/mailman/listinfo/python" rel="noreferrer" target="_blank">http://www.py.cz/mailman/listinfo/python</a><br>
<br>
Visit: <a href="http://www.py.cz" rel="noreferrer" target="_blank">http://www.py.cz</a><br>
</div></div></blockquote></div><br></div>