odeslaní dotazu pomoci ajax a následně zpracovaní odpovědi

vlkodlak

zdravím, ve spolek, prosím o radu či nasměrování na manuál. „zamotal“ jsem se jak na to.
chci vytvořit aplikaci, která odešle na nějakou adresu (např. http://111.222.333.444) ve formátu JSON. A obdrží odpověď ve stejném formátu JSON a následně zobrazí výsledek na stránce pomoci ajaxu.

není mi jasné jak odeslat JSON na http://111.222.333.444, kde běží služba která umí poslouchat a zpracovat JSON
není mi jasné jak zachytím odpověď ze serveru

Kamil Valenta

$data = array("foo" => "bar");
$data_json = json_encode($data);

$result = file_get_contents('http://111.222.333.444', null, stream_context_create(array(
'http' => array(
'method' => 'GET',
'header' => array('Content-Type: application/json'."\r\n"
. 'Content-Length: ' . strlen($data_json) . "\r\n"),
'content' => $data_json)
)
));

vlkodlak

@KamilValenta děkují

Polki

Nepoužívej file_get_contents. To použiješ třeba při načtení souboru z disku, když chceš třeba obsah šupnout klientovi ke stažení apod.
Pro práci mezi servery se daleko více hodí CURL, protože má daleko větší možnosti (různé připojovací protokoly, podporuje HTTPS certifikáty, je několikanásobně rychlejší atp.) Nevýhoda sice je že CURL se píše složitěji, ale už hodně lidí sepsalo nějaké basic skripty, kde zavoláš jeden řádek.

Viz: https://knowledgecornor.blogspot.com/…vs-curl.html

Kamil Valenta

To s tou rychlostí není tak úplně pravda. Hodně článků kopíruje jeden a ten samý test (uvádí se v nich stejné hodnoty), ale když si to člověk zkusí, zjistí, že:
curl: 0.28722476959228516
fgc: 0.1554880142211914

Někdy je ten rozdíl menší. Netvrdím, že cUrl není cesta, knihoven je spousta. Ale nezatracoval bych file_get_contents() jen proto, že je domněle pomalé…

Polki

@KamilValenta Asi to máš trošku pomotaný.
Při jednom volání se může stát cokoliv, takže věřím, že ti ten čas tak vyšel.
Nicméně musíš udělat sérii testů nad soubory, jak se to chová, když ti odpověď vrací nějaký content, jak velký soubor je, různé typy požadavků atd…

Po takové sérii testů dojdeš k tomu, že je cURL na meziserverovou komunikaci několikanásobně rychlejší a proč? Protože FGC vnitřně používá pro tyto účely právě cURL knihovnu. A už z logiky věci, pokud mám něco, co dělá nějakou věc a postavím nad tím něco dalšího, co s tím pracuje, tak to něco, co jsem postavil MUSÍ být logicky pomalejší než to, co je ten základ.

Navíc v FGC nemůžeš nastavit věci jako:

PUT, PATCH, DELETE metody
Kešování odpovědí
Odeslání cookies
Dotaz přes FTP/FTPS připojení
Upravovat/mazat obsah toho souboru
asynchronní požadavky

atd…

FGC omezuje možnosti cURL na pouhé získání obsahu souboru. Proto se používá a byl navržen pro lokální práci se soubory, případně pro práci se soubory v rámci privátní sítě, podobně jako fopen.

A navíc, když se vrátíme k tvému příkladu, který jsi popsal jako odpověď na otázku vlkodlaka, tak jsem si všiml, že používáš metodu GET… Fungovat to bude, ale lepší je post, jelikož s tím si PHP explicitně poradí a nemusíš parsovat data ručně přes „php://input“, na který se mimochodem FGC hodí :D

EDIT: A taky se oplatí zmínit, že nevíš, na čem běží aplikace toho kdo se ptá a dost serverů má právě z důvodů bezpečnosti zakázáno používat FGC na získávání obsahů vzdálených souborů.

Editoval Polki (21. 11. 2020 12:24)

David Matějka

@Polki

Protože FGC vnitřně používá pro tyto účely právě cURL knihovnu

nepouziva cURL, využívá stream wrapper pro HTTP implementovaný zde https://github.com/…en_wrapper.c

A už z logiky věci, pokud mám něco, co dělá nějakou věc a postavím nad tím něco dalšího, co s tím pracuje, tak to něco, co jsem postavil MUSÍ být logicky pomalejší než to, co je ten základ.

tak vzhledem k tomu, že PHP funkce pro práci s cURLem jsou taky „něco dalšího nad tím“, tak i tady máš nějaký overhead

Navíc v FGC nemůžeš nastavit věci jako:
PUT, PATCH, DELETE metody

můžeš

Kešování odpovědí

tohle je věc userlandu i u curlu, ne? ale jestli ti jde o nějaký cachovací hlavičky, tak je nastavit můžeš

Odeslání cookies

můžeš

Dotaz přes FTP/FTPS připojení

PHP má wrapper i pro ftp, takže můžeš

Upravovat/mazat obsah toho souboru

tohle nevím, co tím chceš říct..

asynchronní požadavky

jo, v tomhle máš pravdu

Polki

@DavidMatějka No díky za upřesnění, ale taky asi záleží, jestli se něco od poslední doby, kdy jsem o tom studoval nezměnilo.

Možná bych to s tebou probral někdy podrobněji, protože to vypadá, že máš lepší informace, než například Jan Barášek:
https://php.baraja.cz/curl – 4 měsíce staré tak nevím.

Další info například tady: https://www.geeksforgeeks.org/…curl-in-php/

Kde bereš informace ty? Protože nějakou ofiko dokumentaci jsem k tomu nenašel.

Kamil Valenta

Polki napsal(a):

@KamilValenta Asi to máš trošku pomotaný.

To je celkem odvážné tvrzení, ale respektuju ho jako každý jiný tvůj názor.

Polki napsal(a):

Při jednom volání se může stát cokoliv, takže věřím, že ti ten čas tak vyšel.

Máš pocit, že formulace „Někdy je ten rozdíl menší.“ popisovala jedno jediné měření? Stahoval jsem v obou případech stejný content, samostatně, v cyklu, s různým pořadí cUrl/fgc. Někdy i „vyhrálo“ cUrl, ale rozhodně to bylo jen pár případů. Netvrdím, že je to pravidlo či dogma, možná na to má vliv X jiných věcí. O to více bych netvrdil, že je něco pomalejší mnohonásobně, než to druhé.

Polki napsal(a):

A navíc, když se vrátíme k tvému příkladu, který jsi popsal jako odpověď na otázku vlkodlaka, tak jsem si všiml, že používáš metodu GET… Fungovat to bude, ale lepší je post, jelikož s tím si PHP explicitně poradí a nemusíš parsovat data ručně přes „php://input“, na který se mimochodem FGC hodí :D

Nikoliv. Na získání contentu je GET. Tečka. Taková je specifikace. POST je na založení nové entity. O to víc, pokud tazatel zjevně chce přistupovat na nějaké API, soudě dle požadavku zaslat JSON a JSON stáhnout. Metodu POST na tom zdroji vůbec nemusí mít přístupnou.

Polki napsal(a):

EDIT: A taky se oplatí zmínit, že nevíš, na čem běží aplikace toho kdo se ptá a dost serverů má právě z důvodů bezpečnosti zakázáno používat FGC na získávání obsahů vzdálených souborů.

Ano, nevím, na čem aplikace běží. Takže je lépe poradit mu extensionu, která v defaultu není nainstalovaná? Nemám statistiku, kolik serverů nemá podporu cUrl a kolik jich má zakázané url wrappery. Dokud ani ty takovou statistiku mít nebudeš, je tento argument bezpředmětný.

Polki napsal(a):

Další info například tady: https://www.geeksforgeeks.org/…curl-in-php/

Díky za link, mohl by sis prosím přečíst hned první odstavec a porovnat ho se zadáním tazatele?

Polki

@KamilValenta máš úplnou pravdu promiň.
Já zapomněl, že všechny banky/E-shopy/reCaptcha/platební brány atd. to dělají celou dobu špatně a měly by všechno přepsat aby to vyhovovalo tobě.

Hned dám klientům vědět, aby svoje bankovní API předělali.

Kamil Valenta

Nemusíš se hned urážet. Zároveň nevím, zda dáš ruku do ohně za všechny banky, e-shopy, platební brány…
Není vůbec rozhodující, co vyhovuje mně. Já také někdy používám fgc (třeba právě tam, kde stahuju 1× json), někdy curl (třeba právě tam, kde simuluju paralelní výpočet). Vždy je to o volbě. Myslím, že tazatel dávno ví, jaké možnosti má. Nevím, o co ti jde. Uvedl jsi zde spoustu mylných informací, stěžejní argument stavíš na výkonu a měření tak jednoznačné není. Zkusil sis to změřit také?

P.S. Raději jsi na žádnou z otázek neodpověděl…

Editoval Kamil Valenta (21. 11. 2020 22:11)

David Matějka

@Polki hm, ty články jsou špatně. Barajovi už jsem tam napsal komentář.. já čerpám z ofic doc, případně ze zdrojáků. třeba tady máš popis, co fgc (respektive http stream wrapper) podporuje za options. na implemnetaci toho wrapperu, který nepoužívá curl, jsem už odkázal.
a jak píšu v tom komentáři u baraji, curl je php extension, která závisí na libcurl. fgc na http funguje bez toho.

jo a zkusil jsem benchmark a fgc vychází asi o 25% rychlejší a dokáže ty requesty zpracovat v podstatě stejně rychle jako AB. ale stejně je tohle irelevantní, jelikož overhead jakékoliv http abstrakce těžko překoná síťovou latenci a zpracování požadavku serverem.

jinak v reálný aplikaci bych file_get_contents ani curl přímo nepoužíval, ale sáhnul bych po nějaké abstrakci, která využívá psr http standardy.

vlkodlak

Kamil Valenta napsal(a):

Nikoliv. Na získání contentu je GET. Tečka. Taková je specifikace. POST je na založení nové entity. O to víc, pokud tazatel zjevně chce přistupovat na nějaké API, soudě dle požadavku zaslat JSON a JSON stáhnout. Metodu POST na tom zdroji vůbec nemusí mít přístupnou.

přesně tak to by mělo byt JSON tam a zpět

všem zúčastněným (@DavidMatějka, @Polki, @KamilValenta) velice děkují