Vlákno názorů k článku Webové služby v PHP: XML-RPC a SOAP od Pichi - Zastaralé! REST je všechny přivede, do jednoty sváže.
-
Ale je, jen se to dělá jinak. Je to distribuovatelné a škálovatelné. Určité části jsou cacheovatelné by design. Hlavní princip RESTu je převedení stavové RPC komunikace na bezstavovou. Bezstavový je pouze protokol. Stav je uri. Díky tomu odpadá spousta problémů RPC přístupu v masivně paralelních prostředích. Není překvapivé, že REST používají Google, Yahoo a podobní. Lze směle prohlásit, že Google by bez RESTu měl hodně velký technický problém jak své služby poskytovat. -
(na druhou stranu si spoustu veci muzu nacachovat primo v tom fastrpc serveru nebo v query cache databaze)
Ano, geniální myšlenka to cachovat explicitně u sebe, místo aby to potenciálně cachovala automaticky/implicitně infrastruktura sítě včetně webbrowseru uživatele.co se distribuovatelnosti a skalovatelnosti tyce, nevidim rozdil
Vzhledem k tomu, že každý request je selfdescribing (protokol je bezstavový a tak jiný ani nemůže být) je také řešitelný na libovolném stroji v clusteru a by design už záleží jestli to bude nebo nebude sdílet zdroje. RPC sdílí zdroje mezi requesty by design. -
edois (neregistrovaný)>>Ano, geniální myšlenka to cachovat explicitně u sebe, místo aby to potenciálně cachovala automaticky/implicitně infrastruktura sítě včetně webbrowseru uživatele.
ano, protoze kdyz cachuje vyssi vrstva, tak se nedozvi, ze uz to vyprselo a ze to cachovat nema.
konkretne ten browser to cachuje do te doby, dokud si "mysli", ze je to fresh. ale ono uz treba neni... -
beer (neregistrovaný)jednoduche vysvetleni: LOGIKA A STATISTIKA :)
slozite:
kazda data maji svoji vicemene lehce urcitelnou splatnost, ktera se poslou spolu s prvnim odpovedi na dotaz klienta, smerujici na urcita data. Dulezita je synchronizace server-klient, obe casti sdileji spolecny standard. Klient se pak rozhodne kdy si o data opet rekne. Do te doby pracuje s daty predchoziho dotazu:
nemenna data
data s presnou platnost
data s platnosti do konce session
data, ktera se musi nacitat pokazde
timto lze na strane browseru vyborne cachovat, rizeni ale provadi server a tam probiha optimalizace, staci jen spravne (napriklad podle statistickych dat) urcit minimalni dobu platnosti dat a pak je jen na uvazeni, zda-li se vyplati data cachovat, to uz jsou pak konkretni reseni a to je podle me nejlepe si projit sam a v klidu .)
btw: python -
edois (neregistrovaný)cachovani na strane browseru ma u nekterych dat cenu, ale u _vetsiny_ dat (z vlastni zkusenosti) to cenu nema, protoze prave nevim, jak dlouho to muzu "beztrestne" cachovat. nektere veci se treba 2 hodiny nezmeni a pak se zmeni 3x za 20 sekund. proto fakt radsi cachuju na strane databaze, serveru, ... a na strane klienta cachuju takovy veci, jako jsou obrazky, css, javascripty atd., ale zbytek radsi moc ne. to, co na strankach delavam ajaxem, proste nebyva cachovatelne. a to, co je GET, se da bez problemu cachovat lighttpd.
jj s pythonem souhlasim, jeho kombinace s c++ je primo vrazedna ;)
