Ëndrra për të cilën u krijua Rrjeti është e zakonshme hapësirë informacioni, në të cilën ne komunikojmë duke shkëmbyer informacion. Shkathtësia e tij është një pjesë integrale e tij: një lidhje hiperteksti mund të çojë kudo, qoftë informacion personal, lokal apo global, një draft ose tekst i korrigjuar.
Tim Bernes-Lee, World Wide Web: Një histori shumë e shkurtër personale
Protokolli Nëse shkruani eloquentjavascript.net/17_http.html në shiritin e adresave të shfletuesit, shfletuesi së pari do të njohë adresën e serverit të lidhur me emrin eloquentjavascript.net dhe do të përpiqet të hapë Lidhja TCP në portin 80 – porti i paracaktuar HTTP. Nëse serveri ekziston dhe pranon lidhjen, shfletuesi dërgon diçka si:GET /17_http.html HTTP/1.1
Pritësi: eloquentjavascript.net
Përdoruesi-Agjent: Emri i shfletuesit
Serveri përgjigjet në të njëjtën lidhje:
HTTP/1.1 200 OK
Përmbajtja-Gjatësia: 65585
Lloji i përmbajtjes: tekst/html
...pjesën tjetër të dokumentit
Shfletuesi merr pjesën që vjen pas përgjigjes vijë bosh dhe e shfaq atë si një dokument HTML.
Informacioni i dërguar nga klienti quhet kërkesë. Fillon me rreshtin:
GET /17_http.html HTTP/1.1
Fjala e parë është metoda e kërkesës. GET do të thotë që ne duhet të marrim një burim specifik. Metoda të tjera të zakonshme janë DELETE për të fshirë, PUT për të zëvendësuar dhe POST për të dërguar informacion. Vini re se serverit nuk i kërkohet të përmbushë çdo kërkesë që merr. Nëse zgjidhni një sajt të rastësishëm dhe i thoni DELETE faqen kryesore- Ai me shumë mundësi do të refuzojë.
Pjesa pas emrit të metodës është shtegu drejt burimit në të cilin është dërguar kërkesa. Në rastin më të thjeshtë, burimi është vetëm një skedar në server, por protokolli nuk është i kufizuar në këtë mundësi. Një burim mund të jetë çdo gjë që mund të transferohet si skedar. Shumë serverë gjenerojnë përgjigje në fluturim. Për shembull, nëse hapni twitter.com/marijnjh, serveri do të kërkojë në bazën e të dhënave përdoruesin marijnjh dhe nëse e gjen, do të krijojë një faqe profili për atë përdorues.
Duke ndjekur rrugën e burimit, rreshti i parë i kërkesës përmend HTTP/1.1 për të treguar versionin e protokollit HTTP që po përdor.
Përgjigja e serverit gjithashtu fillon me versionin e protokollit, e ndjekur nga statusi i përgjigjes - së pari kodi nga tre shifra, pastaj vijë.
HTTP/1.1 200 OK
Kodet e statusit që fillojnë me 2 tregojnë kërkesa të suksesshme. Kodet që fillojnë me 4 do të thotë se diçka ka shkuar keq. 404 është statusi më i famshëm HTTP, që tregon se burimi i kërkuar nuk mund të gjendej. Kodet që fillojnë me 5 tregojnë se ka pasur një gabim në server, por jo fajin e kërkesës.
Rreshti i parë i një kërkese ose përgjigje mund të ndiqet nga çdo numër i rreshtave të titullit. Këto janë vargje në formën "emri: vlera" që tregojnë Informacion shtese në lidhje me një kërkesë ose përgjigje. Këto tituj janë përfshirë në shembull:
Përmbajtja-Gjatësia: 65585
Lloji i përmbajtjes: tekst/html
Ndryshuar së fundi: e mërkurë, 9 prill 2014 10:48:09 GMT
Këtu përcaktohet madhësia dhe lloji i dokumentit të marrë si përgjigje. NË në këtë rast Ky është një dokument HTML me masë 65'585 bajt. Ai gjithashtu tregon se kur dokumenti është modifikuar për herë të fundit.
Në pjesën më të madhe, klienti ose serveri përcakton se cilat tituj duhet të përfshihen në kërkesë ose përgjigje, megjithëse kërkohen disa tituj. Për shembull, Host, që tregon emrin e hostit, duhet të përfshihet në kërkesë sepse një server mund të shërbejë shumë emra host në një adresë IP të vetme dhe pa këtë kokë, serveri nuk do ta dijë me cilin host klienti po përpiqet të komunikojë.
Pas titujve, si kërkesa ashtu edhe përgjigja mund të specifikojnë një rresht bosh të ndjekur nga një trup që përmban të dhënat që do të transmetohen. Kërkesat GET dhe DELETE nuk dërgojnë të dhëna shtesë, por dërgojnë PUT dhe POST. Disa përgjigje, të tilla si mesazhet e gabimit, nuk kërkojnë një trup.
Shfletuesi dhe HTTP Siç e pamë në shembull, shfletuesi dërgon një kërkesë kur futim një URL shiriti i adresave. Kur në marrë dokument HTML përmban referenca për skedarë të tjerë, si p.sh. fotografi ose Skedarët JavaScript, kërkohen edhe nga serveri.Një faqe interneti mesatare mund të përmbajë lehtësisht 10 deri në 200 burime. Për të qenë në gjendje t'i kërkojnë ato më shpejt, shfletuesit bëjnë kërkesa të shumta njëherësh në vend që të presin që kërkesat të përfundojnë njëra pas tjetrës. Dokumentet e tilla kërkohen gjithmonë nëpërmjet kërkesave GET.
Aktiv faqet HTML Mund të ketë forma që i lejojnë përdoruesit të fusin informacionin dhe ta dërgojnë atë në server. Këtu është një formular shembull:
Emri:
Mesazh:
Dërgo
Kodi përshkruan një formë me dy fusha: e vogla kërkon një emër dhe e madhja kërkon një mesazh. Kur klikoni butonin "Dërgo", informacioni nga këto fusha do të kodohet në një varg pyetjesh. Kur atributi i metodës së një elementi është GET, ose kur nuk specifikohet fare, vargu i pyetjes vendoset në URL nga fusha e veprimit dhe shfletuesi bën një kërkesë GET me atë URL.
GET /example/message.html?name=Jean&message=Po%3F HTTP/1.1
Fillimi i vargut të pyetjes tregohet me një pikëpyetje. Kjo pasohet nga çifte emrash dhe vlerash që korrespondojnë me atribut emri fushat e formës dhe përmbajtjen e këtyre fushave. Ampersand (&) përdoret për t'i ndarë ato.
Mesazhi i dërguar në shembull përmban vargun "Po?", megjithëse pikëpyetja zëvendësohet nga një kod i çuditshëm. Disa karaktere në vargun e pyetjes duhet të shmangen. Pikëpyetja është përfshirë dhe përfaqësohet nga kodi %3F. Ekziston një rregull i pashkruar që çdo format duhet të ketë një mënyrë për t'i shpëtuar personazheve. Ky është një rregull i quajtur Kodimi i URL-së përdor një përqindje të ndjekur nga dy shifra heksadecimal që përfaqësojnë kodin e karakterit. 3F në dhjetor do të ishte 63, dhe ky është kodi për pikëpyetjen. JavaScript ka funksione encodeURIcomponent dhe decodeURIcomponent për kodim dhe dekodim.
Console.log(encodeURIcomponent("Përshëndetje dhe mirupafshim")); // → Hello%20%26%20mirupafshim console.log(decodeURIcomponent("Hello%20%26%20lamtumirë")); // → Përshëndetje dhe lamtumirë
Nëse e ndryshojmë atributin e metodës në formularin në shembullin e mëparshëm në POST, Kërkesa HTTP me dorëzimin e formularit do të bëhet duke përdorur Metoda POST, i cili do të dërgojë vargun e pyetjes në trupin e kërkesës, në vend që ta shtojë atë në URL.
POST /example/message.html HTTP/1.1
Gjatësia e përmbajtjes: 24
Lloji i përmbajtjes: aplikacion/x-www-form-urlencoded
Emri=Jean&message=Po%3F
Me marrëveshje Metoda GET përdoret për pyetje që nuk kanë efekte anësore, të tilla si kërkimi. Kërkesat që ndryshojnë diçka në server krijohen llogari e re ose postimi i një mesazhi duhet të dërgohet duke përdorur metodën POST. Programet e klientëve Llojet e shfletuesit e dinë se nuk ka nevojë të bëhen thjesht kërkesa POST, dhe nganjëherë ata bëjnë kërkesa GET pa u vënë re nga përdoruesi - për shembull, për të shkarkuar paraprakisht përmbajtje që përdoruesit mund t'i nevojiten së shpejti.
Në kapitullin tjetër, ne do të kthehemi te formularët dhe do të flasim se si mund t'i bëjmë ato duke përdorur JavaScript.
XMLHttpRequest Ndërfaqja përmes së cilës JavaScript në shfletues mund të bëjë kërkesa HTTP quhet XMLHttpRequest (vini re se si kërcen madhësia e shkronjave). Është zhvilluar nga Microsoft për shfletuesin Internet Explorer në fund të viteve 1990. Në atë kohë Formati XML ishte shumë popullor në botën e softuerit të biznesit - dhe në këtë botë Microsoft gjithmonë është ndjerë si në shtëpinë e tij. Ishte aq popullor saqë shkurtesa XML u fiksua përpara emrit të ndërfaqes për të punuar me HTTP, megjithëse kjo e fundit nuk lidhet fare me XML.Megjithatë, emri nuk është plotësisht i pakuptimtë. Ndërfaqja ju lejon të analizoni përgjigjet sikur të ishin dokumente XML. Përzierja e dy gjërave të ndryshme (analizimi i kërkesës dhe përgjigjes) në një është, sigurisht, një dizajn i neveritshëm, por çfarë mund të bëni.
Kur ndërfaqja XMLHttpRequest u shtua në Internet Explorer, u bë e mundur të bëheshin gjëra që më parë ishin shumë të vështira për t'u bërë. Për shembull, faqet filluan të shfaqin lista sugjerimesh ndërsa përdoruesi fut diçka në një fushë teksti. Skripti dërgon tekst në server nëpërmjet HTTP në të njëjtën kohë kur përdoruesi është duke shtypur. Server që ka një bazë të dhënash për opsionet e mundshme input, kërkon për hyrje të përshtatshme midis hyrjeve dhe i kthen ato për t'u shfaqur. Dukej shumë bukur - njerëzit më parë ishin mësuar të prisnin që e gjithë faqja të ringarkohej pas çdo ndërveprimi me sitin.
Një tjetër shfletues i rëndësishëm Në atë kohë, Mozilla (më vonë Firefox) nuk donte të mbetej prapa. Për të lejuar që të ndodhin gjëra të ngjashme, Mozilla kopjoi ndërfaqen së bashku me emrin. Gjenerata e ardhshme e shfletuesve ndoqi shembullin dhe sot XMLHttpRequest është standardi de fakto.
Dërgimi i një kërkese Për të dërguar një kërkesë të thjeshtë, ne krijojmë një objekt kërkese me një konstruktor XMLHttpRequest dhe thërrasim metodat e hapjes dhe dërgimit.Var req = new XMLHttpRequest(); req.open("GET", "shembull/data.txt", false); kër.send(null); console.log (req.responseText); // → Kjo është përmbajtja e të dhënave.txt
Metoda e hapur vendos kërkesën. Në rastin tonë, ne vendosëm të bëjmë një kërkesë GET për skedarin shembull/data.txt. URL-të që nuk fillojnë me emrin e protokollit (për shembull, http :) quhen relative, domethënë interpretohen në lidhje me dokument aktual. Kur fillojnë me një të pjerrët (/), ata zëvendësojnë shtegun aktual - pjesën pas emrit të serverit. Ndryshe pjesë rrugën aktuale deri në prerjen e fundit vendoset përpara URL-së relative.
Pas hapjes së kërkesës, ne mund ta dërgojmë atë duke përdorur metodën e dërgimit. Argumenti është trupi i kërkesës. Për kërkesat GET, përdoret null. Nëse argumenti i tretë për t'u hapur ishte i rremë, atëherë dërgimi do të kthehet vetëm pasi të jetë marrë një përgjigje për kërkesën tonë. Për të marrë trupin e përgjigjes, mund të lexojmë veçorinë answerText të objektit të kërkesës.
Mund të merrni informacione të tjera nga objekti i përgjigjes. Kodi i statusit është i disponueshëm në veçorinë e statusit dhe teksti i statusit është i disponueshëm në statusText. Titujt mund të lexohen nga getResponseHeader.
Var req = new XMLHttpRequest(); req.open("GET", "shembull/data.txt", false); kër.send(null); console.log (req.status, req.statusText); // → 200 OK console.log(req.getResponseHeader("lloji i përmbajtjes")); // → tekst/i thjeshtë
Emrat e titujve nuk janë të ndjeshëm ndaj shkronjave të vogla. Zakonisht shkruhen me shkronje e madhe në fillim të çdo fjale, për shembull "Lloji i përmbajtjes", por "lloji i përmbajtjes" ose "Lloji i përmbajtjes" do të përshkruajnë të njëjtin titull.
Vetë shfletuesi do të shtojë disa tituj, si "Host" dhe të tjerë, që serverit i nevojiten për të llogaritur madhësinë e trupit. Por ju mund të shtoni titujt tuaj duke përdorur metodën setRequestHeader. Kjo është e nevojshme për Raste të veçanta dhe kërkon bashkëpunimin e serverit në të cilin po aksesoni - është e lirë të shpërfillni titujt që nuk mund t'i përpunojë.
Kërkesat asinkrone Në shembull, kërkesa përfundoi kur mbaroi telefonata e dërgimit. Kjo është e përshtatshme sepse vetitë si përgjigjeText janë të disponueshme menjëherë. Por kjo do të thotë që programi ynë do të presë derisa shfletuesi dhe serveri të komunikojnë me njëri-tjetrin. Në lidhje e keqe, server i dobët ose skedar i madh kjo mund të marrë kohe e gjate. Kjo është gjithashtu e keqe sepse asnjë mbajtës i ngjarjeve nuk do të aktivizohet ndërsa programi është në modalitetin e gatishmërisë - dokumenti nuk do t'i përgjigjet veprimeve të përdoruesit.Nëse kalojmë true si argumentin e tretë për t'u hapur, kërkesa do të jetë asinkrone. Kjo do të thotë që kur thirret dërgimi, kërkesa është në radhë për dërgim. Programi vazhdon të funksionojë dhe shfletuesi kujdeset për dërgimin dhe marrjen e të dhënave në sfond.
Por ndërkohë që kërkesa është duke u përpunuar, ne nuk do të marrim përgjigje. Ne kemi nevojë për një mekanizëm njoftimi që të dhënat kanë mbërritur dhe janë gati. Për ta bërë këtë, do të duhet të dëgjojmë ngjarjen "ngarkesa".
Var req = new XMLHttpRequest(); req.open("GET", "shembull/data.txt", true); req.addEventListener("load", funksion() ( console.log("Done:", req.status); )); kërk.send(null);
Ashtu si thirrja në requestAnimationFrame në Kapitullin 15, ky kod na detyron të përdorim një stil programimi asinkron duke e mbështjellë kodin që duhet të ekzekutohet pas kërkesës në një funksion dhe duke thirrur funksionin. Koha e duhur. Ne do të kthehemi në këtë më vonë.
Marrja e të dhënave XMLKur burimi i kthyer nga objekti XMLHttpRequest është një dokument XML, vetia answerXML do të përmbajë një paraqitje të analizuar të dokumentit. Ai funksionon në mënyrë të ngjashme me DOM-in, me përjashtim të faktit se nuk ka funksionalitet vendas HTML si vetia e stilit. Objekti i përmbajtur në answerXML korrespondon me objektin e dokumentit. Vetia e tij documentElement i referohet etiketës së jashtme të dokumentit XML. NË dokumenti tjetër(shembull/frut.xml) kjo etiketë do të ishte:
Mund të marrim një skedar të tillë si ky:
Var req = new XMLHttpRequest(); req.open("GET", "shembull/frut.xml", false); kër.send(null); console.log(req.responseXML.querySelectorAll("fruta").length); // → 3
Dokumentet XML mund të përdoren për të shkëmbyer me serverin informacion të strukturuar. Forma e tyre - etiketat e mbivendosura - është e përshtatshme për ruajtjen e shumicës së të dhënave, ose të paktën më mirë se skedarët e tekstit. Ndërfaqja DOM është e ngathët kur bëhet fjalë për marrjen e informacionit dhe dokumente XML rezultojnë të jenë mjaft të folur. Zakonisht është më mirë të komunikosh duke përdorur të dhëna JSON, të cilat janë më të lehta për t'u lexuar dhe shkruar si për programet ashtu edhe për njerëzit.
Var req = new XMLHttpRequest(); req.open("GET", "shembull/frut.json", false); kër.send(null); console.log(JSON.parse(req.responseText)); // → (banane: "e verdhë", limon: "e verdhë", qershi: "e kuqe")
HTTP Sandbox Kërkesat HTTP nga një faqe interneti ngrenë shqetësime për sigurinë. Personi që kontrollon skriptin mund të ketë interesa të ndryshme nga interesat e përdoruesit në kompjuterin e të cilit funksionon. Konkretisht, nëse shkoj te themafia.org, nuk dua që skriptet e tyre të mund të bëjnë kërkesa për mybank.com duke përdorur informacionin e shfletuesit tim si identifikues dhe t'i udhëzoj që të dërgojnë të gjitha paratë e mia në ndonjë llogari mafioze.Faqet e internetit mund të mbrohen nga sulme të tilla, por për ta bërë këtë kërkon disa përpjekje dhe shumë sajte dështojnë ta bëjnë këtë. Për shkak të kësaj, shfletuesit i mbrojnë ata duke i penguar skriptet që të bëjnë kërkesa në domene të tjera (emra si themafia.org dhe mybank.com).
Kjo mund të ndërhyjë në zhvillimin e sistemeve që duhet të kenë akses fusha të ndryshme për një arsye të mirë. Për fat të mirë, serveri mund të përfshijë kokën e mëposhtme në përgjigje, duke ua bërë të qartë shfletuesve se kërkesa mund të vijë nga fusha të tjera:
Access-Control-Allow-Origin: *
Abstraktimi i pyetjeve Në Kapitullin 10 në zbatimin tonë sistem modular AMD kemi përdorur një funksion hipotetik backgroundReadFile. Mori një emër skedari dhe një funksion, dhe e thirri atë funksion pasi lexoi përmbajtjen e skedarit. Këtu zbatim i thjeshtë ky funksion:Funksioni backgroundReadFile(url, callback) ( var req = new XMLHttpRequest(); req.open("GET", url, true); req.addEventListener("load", function() ( if (req.status< 400) callback(req.responseText); }); req.send(null); }
Abstraksioni i thjeshtë e bën të lehtë përdorimin e XMLHttpRequest për kërkesa të thjeshta GET. Nëse jeni duke shkruar një program që bën kërkesa HTTP, është mirë të përdorni një funksion ndihmës në mënyrë që të mos keni nevojë të përsërisni modelin e shëmtuar XMLHttpRequest gjatë gjithë kohës.
Argumenti i kthimit të thirrjes është një term që përdoret shpesh për të përshkruar funksione të tilla. Funksioni i kthimit të thirrjes i kalohet një kodi tjetër në mënyrë që të mund të na telefonojë më vonë.
Është e lehtë të shkruani funksionin tuaj ndihmës HTTP, të përshtatur posaçërisht për programin tuaj. I mëparshmi bën vetëm kërkesa GET dhe nuk na jep kontroll mbi kokat e kërkesës ose trupin. Mund të shkruani një opsion tjetër për kërkesën POST, ose një më të përgjithshëm që mbështet kërkesa të ndryshme. Shumë biblioteka JavaScript ofrojnë mbështjellës për XMLHttpRequest.
Problemi kryesor me mbështjellësin e dhënë është trajtimi i gabimeve. Kur një kërkesë kthen një kod statusi që tregon një gabim (400 ose më i lartë), nuk bën asgjë. Në disa raste kjo është në rregull, por imagjinoni nëse vendosim një tregues ngarkimi në faqe për të treguar se po marrim informacion. Nëse kërkesa dështon sepse serveri u rrëzua ose lidhja u ndërpre, faqja do të pretendojë se është e zënë me diçka. Përdoruesi do të presë pak, atëherë ai do të mërzitet dhe do të vendosë që faqja është disi budalla.
Ne kemi nevojë për një opsion ku marrim një paralajmërim për një kërkesë të dështuar në mënyrë që të mund të ndërmarrim veprime. Për shembull, ne mund të heqim mesazhin e ngarkimit dhe t'i bëjmë të ditur përdoruesit se diçka shkoi keq.
Trajtimi i gabimeve në kodin asinkron është edhe më i vështirë sesa në kodin sinkron. Meqenëse shpesh na duhet të ndajmë një pjesë të punës dhe ta vendosim atë në një funksion të kthimit të thirrjes, shtrirja e bllokut të provoni bëhet e pakuptimtë. Në kodin e mëposhtëm, përjashtimi nuk do të kapet sepse thirrja në backgroundReadFile kthehet menjëherë. Kontrolli më pas largohet nga blloku i "provës" dhe funksioni në të nuk do të thirret.
Provoni ( backgroundReadFile("example/data.txt", funksion(tekst) ( if (tekst != "pritet") hidhni një gabim të ri ("Kjo ishte e papritur"); )); ) kap (e) (consol.log( "Përshëndetje nga blloku i kapjes");)
Për të trajtuar kërkesat e pasuksesshme, do të duhet të kaloni funksion shtesë në mbështjellësin tonë dhe thirreni në rast problemesh. Një opsion tjetër është përdorimi i konventës që nëse kërkesa dështon, atëherë një argument shtesë i kalohet funksionit të kthimit të thirrjes që përshkruan problemin. Shembull:
Funksioni getURL(url, kthimi i thirrjes) ( var req = i ri XMLHttpRequest(); req.open("GET", url, true); req.addEventListener("load", function() ( if (req.status< 400) callback(req.responseText); else callback(null, new Error("Request failed: " + req.statusText)); }); req.addEventListener("error", function() { callback(null, new Error("Network error")); }); req.send(null); }
Kodi që përdor getURL duhet të kontrollojë për të parë nëse është kthyer një gabim dhe ta trajtojë atë nëse ka një të tillë.
GetURL("data/nonsense.txt", funksioni(përmbajtja, gabimi) ( if (gabim != null) console.log("Dështoi të merrja nonsense.txt: " + gabim); else console.log("nonsense.txt : " + përmbajtja); ));
Kjo nuk ndihmon me përjashtime. Kur kryejmë disa veprime asinkrone me radhë, një përjashtim në çdo pikë të zinxhirit në çdo rast (përveç nëse e mbështillni secilin mbajtës në bllokun e tij të provoni/kapjes) do të hidhet në nivelin më të lartë dhe do të ndërpresë të gjithë zinxhirin.
Premtimet Është e vështirë për të shkruar kod asinkron projekte komplekse në formë të thjeshtë kthimet e thirrjeve. Është e lehtë të harrosh të kontrollosh për gabime ose të lejosh që një përjashtim i papritur të përfundojë papritmas programin tënd. Përveç kësaj, organizata përpunimi i saktë gabimet dhe kalimi i gabimit përmes thirrjeve të shumta të njëpasnjëshme është shumë e lodhshme.Ka pasur shumë përpjekje për ta zgjidhur këtë problem me abstraksione shtesë. Një nga përpjekjet më të suksesshme quhet premtime. Premtimet mbështjellin një veprim asinkron në një objekt që mund të kalohet dhe duhet të bëjë disa gjëra kur veprimi përfundon ose dështon. Një ndërfaqe e tillë tashmë është bërë pjesë e rrymës Versionet e JavaScript, dhe për versionet më të vjetra mund të përdoret si bibliotekë.
Ndërfaqja e premtimeve nuk është veçanërisht intuitive, por është e fuqishme. Në këtë kapitull do ta përshkruajmë vetëm pjesërisht. Më shumë informacion mund të gjendet në www.promisejs.org
Për të krijuar një objekt premtimesh, ne e quajmë konstruktorin Promise, duke i dhënë një funksion për të inicializuar një veprim asinkron. Konstruktori e quan këtë funksion dhe i kalon dy argumente, të cilët janë vetë funksione. I pari duhet të quhet në një rast të suksesshëm, tjetri në një rast të pasuksesshëm.
Dhe këtu është mbështjellësi ynë i kërkesës GET, i cili këtë herë na kthen një premtim. Tani ne thjesht do ta quajmë marrë.
Funksioni get(url) ( kthimi i premtimit të ri (funksioni (sukses, dështon) ( var req = i ri XMLHttpRequest (); req.open ("GET", url, i vërtetë); req.addEventListener ("load", funksion() ( nëse (kërk.statusi< 400) succeed(req.responseText); else fail(new Error("Request failed: " + req.statusText)); }); req.addEventListener("error", function() { fail(new Error("Network error")); }); req.send(null); }); }
Ju lutemi vini re se ndërfaqja me vetë funksionin është thjeshtuar. Ne i kalojmë një URL dhe ai kthen një premtim. Ai vepron si një mbajtës për daljen e kërkesës. Ajo ka një metodë më pas që thirret me dy funksione: një për të trajtuar suksesin dhe një për të trajtuar dështimin.
Get("shembull/data.txt").then(funksion(tekst) ( console.log("data.txt: " + tekst); ), funksion(gabim) ( console.log("Dështoi të marrë të dhënat.txt : " + gabim); ));
Për momentin, kjo është ende një mënyrë për të shprehur atë që kemi bërë tashmë. Është vetëm kur keni një zinxhir ngjarjesh që një ndryshim i dukshëm bëhet i dukshëm.
Më pas, thirrja prodhon një premtim të ri, rezultati i të cilit (vlera e kaluar te mbajtësit e suksesit) varet nga vlera e kthimit të funksionit të parë që i kaluam atëherë. Ky funksion mund të kthejë një premtim tjetër, duke treguar se po kryhet punë shtesë asinkrone. Në këtë rast, premtimi i kthyer deri atëherë vetë do të presë për premtimin e kthyer nga funksioni mbajtës, dhe suksesi ose dështimi do të ndodhë me të njëjtën vlerë. Kur një funksion mbajtës kthen një vlerë që nuk është premtim, premtimi i kthyer deri atëherë bëhet i suksesshëm, duke e përdorur atë vlerë si rezultat.
Kjo do të thotë që ju mund ta përdorni atë për të ndryshuar rezultatin e një premtimi. P.sh. funksioni tjetër kthen një premtim, rezultati i të cilit është përmbajtja nga URL-ja e dhënë e analizuar si JSON:
Funksioni getJSON(url) (ktheje get(url).pastaj(JSON.parse); )
Thirrja e fundit atëherë nuk specifikoi një mbajtës të dështimit. Kjo është e pranueshme. Gabimi do të kalojë në premtimin e kthyer përmes asaj kohe, gjë që na nevojitet - getJSON nuk di çfarë të bëjë kur diçka nuk shkon, por shpresojmë se kodi që e thërret e di.
Si shembull që tregon përdorimin e premtimeve, ne do të shkruajmë një program që merr një numër skedarësh JSON nga serveri dhe shfaq fjalën "shkarko" kur kërkesa të ekzekutohet. Skedarët përmbajnë informacione për njerëzit dhe lidhje me skedarë të tjerë me informacione për persona të tjerë në prona si babai, nëna, bashkëshorti.
Duhet të marrim emrin e nënës së bashkëshortit nga shembull/bert.json. Në rast problemesh, duhet të heqim tekstin "ngarkues" dhe të shfaqim një mesazh gabimi. Ja se si mund ta bëni duke përdorur premtime:
funksioni showMessage(msg) ( var elt = document.createElement ("div"); elt.textContent = msg; kthe dokument.body.appendChild(elt); ) var loading = showMessage("Po ngarkohet..."); getJSON("shembull/bert.json").then(funksioni(bert) (kthimi getJSON(bert.bashkëshorti); )).then(funksioni(bashkëshorti) (kthimi getJSON(bashkëshorti.mama);)).pastaj(funksioni (nëna) ( showMessage ("Emri - " + nëna.emri); )).catch(function(gabim) ( showMessage(String(gabim)); )).then(function() (dokument.body.removeChild(duke u ngarkuar );));
Programi përfundimtar është relativisht kompakt dhe i lexueshëm. Metoda e kapjes është e ngjashme me atë të asaj kohe, por ajo pret vetëm një mbajtës për rezultatin e pasuksesshëm dhe, nëse është i suksesshëm, kalon në rezultatin e pandryshuar. Ekzekutimi i programit do të vazhdojë në mënyrën e zakonshme pas kapjes së përjashtimit - ashtu si në rastin e try/catch. Pra, e fundit pastaj, e cila heq mesazhin e ngarkimit, ekzekutohet gjithsesi, edhe nëse dështon.
Ju mund të mendoni për ndërfaqen e premtimit si një gjuhë të veçantë për përpunimin asinkron të ekzekutimit të programit. Thirrjet shtesë për metodat dhe funksionet që nevojiten për ta bërë atë të funksionojë i japin kodit një pamje disi të çuditshme, por jo aq të papërshtatshme sa trajtimi manual i të gjitha gabimeve.
Vlerësoni HTTP-në Kur krijoni një sistem në të cilin një program JavaScript në shfletues (klient) komunikon me program server, mund të përdorni disa opsione për modelimin e një komunikimi të tillë.Një metodë e zakonshme janë thirrjet e procedurës në distancë. Në këtë model, komunikimi ndjek modelin e thirrjeve të rregullta të funksioneve, vetëm këto funksione ekzekutohen në një kompjuter tjetër. Thirrja është për të krijuar një kërkesë në server që përfshin emrin e funksionit dhe argumentet. Përgjigja ndaj kërkesës përfshin një vlerë kthimi.
Kur përdorni thirrjet e procedurës në distancë, HTTP është thjesht një transport për komunikim dhe ka të ngjarë të shkruani një shtresë abstraksioni që e fsheh atë plotësisht.
Një qasje tjetër është të ndërtoni sistemin tuaj të komunikimit rreth konceptit të burimeve dhe metodave HTTP. Në vend që të telefononi një procedurë në distancë të quajtur addUser, ju bëni Kërkesa PUT te /users/larry. Në vend që të kodoni vetitë e përdoruesit në argumentet e funksionit, ju specifikoni formatin ose përdorimin e dokumentit format ekzistues, i cili do të përfaqësojë përdoruesin. Trupi i kërkesës PUT që krijon burim i ri, do të jetë thjesht një dokument i këtij formati. Një burim merret përmes një kërkese GET në URL-në e tij (/user/larry), i cili kthen një dokument që përfaqëson atë burim.
Qasja e dytë e bën më të lehtë përdorimin e disa Aftësitë HTTP, për shembull, mbështetje për ruajtjen e burimeve (një kopje e burimit ruhet në anën e klientit). Ndihmon gjithashtu në krijimin e një ndërfaqeje të qëndrueshme, sepse është më e lehtë të mendosh për sa i përket burimeve sesa për funksionet.
Siguria dhe të dhënat HTTPS udhëtojnë nëpër internet përgjatë një rruge të gjatë dhe të rrezikshme. Për të arritur në destinacionin e tyre, ata duhet të kërcejnë mbi të gjitha llojet e vendeve, duke filluar nga Rrjetet Wi-Fi kafenetë në rrjete të kontrolluara organizata të ndryshme dhe shtetet. Në çdo moment gjatë rrugës ato mund të lexohen apo edhe të ndryshohen.Nëse ju duhet të mbani diçka sekrete, të tilla si fjalëkalimet e emailit, ose nëse të dhënat duhet të mbërrijnë në destinacionin e tyre të pandryshuara - siç është numri i llogarisë bankare në të cilën po transferoni para - HTTP e thjeshtë nuk mjafton.
HTTP i sigurt, URL-të e të cilit fillojnë me https://, mbështjell trafikun HTTP në mënyrë që të jetë më e vështirë për t'u lexuar dhe ndryshuar. Së pari, klienti verifikon që serveri është ai që thotë se është duke i kërkuar serverit të paraqesë një certifikatë kriptografike të lëshuar nga një palë autoritative që shfletuesi e njeh. Më pas, të gjitha të dhënat që kalojnë përmes lidhjes kodohen për të parandaluar përgjimin dhe ndryshimin.
Pra, kur gjithçka funksionon si duhet, HTTPS parandalon si rastet e dikujt që pretendon të jetë një uebsajt tjetër me të cilin po komunikoni, ashtu edhe rastet e përgjimit të komunikimit tuaj. Nuk është perfekt dhe ka pasur raste kur HTTPS ka dështuar për shkak të certifikatave të rreme ose të vjedhura ose softuerit të prishur. Sidoqoftë, është shumë e lehtë të bësh diçka të keqe me HTTP, dhe hakimi i HTTPS kërkon atë lloj përpjekjeje që mund të bëjnë vetëm agjencitë qeveritare ose organizatat kriminale shumë serioze (dhe ndonjëherë nuk ka asnjë ndryshim midis këtyre organizatave).
Përmbledhje Në këtë kapitull, ne pamë se HTTP është një protokoll për aksesimin e burimeve në internet. Klienti dërgon një kërkesë që përmban një metodë (zakonisht GET) dhe një shteg që specifikon burimin. Serveri vendos se çfarë të bëjë me kërkesën dhe përgjigjet me një kod statusi dhe një organ përgjigjeje. Kërkesat dhe përgjigjet mund të përmbajnë tituj që përcjellin informacion shtesë.Shfletuesit bëjnë kërkesa GET për të marrë burimet e nevojshme për të shfaqur një faqe. Faqja mund të përmbajë formularë që lejojnë që informacioni i futur nga përdoruesi të dorëzohet në një kërkesë që krijohet pas dorëzimit të formularit. Do të mësoni më shumë rreth kësaj në kapitullin vijues.
Ndërfaqja përmes së cilës JavaScript bën kërkesa HTTP nga shfletuesi quhet XMLHttpRequest. Ju mund të injoroni prefiksin "XML" (por ju ende duhet ta shkruani atë). Mund të përdoret në dy mënyra: sinkron, i cili bllokon të gjithë punën derisa kërkesa të përfundojë, dhe asinkron, i cili kërkon instalimin e një mbajtësi të ngjarjeve që monitoron përfundimin e kërkesës. Pothuajse në të gjitha rastet është e preferueshme mënyrë asinkrone. Krijimi i një kërkese duket si ky:
Var req = new XMLHttpRequest(); req.open("GET", "shembull/data.txt", true); req.addEventListener("load", funksion() ( console.log(req.statusCode); )); kërk.send(null);
Programimi asinkron nuk është një gjë e lehtë. Premtimet janë një ndërfaqe që e bën më të lehtë duke ndihmuar në drejtimin e mesazheve të gabimit dhe përjashtimeve në trajtuesin e duhur dhe duke hequr disa nga elementët e përsëritshëm të prirur ndaj gabimeve.
Ushtrime Negocimi i përmbajtjes Një nga gjërat që HTTP mund të bëjë dhe që nuk e kemi diskutuar quhet negociata e përmbajtjes. Kreu Prano në një kërkesë mund të përdoret për t'i treguar serverit se çfarë lloj dokumentesh dëshiron të marrë klienti. Shumë serverë e injorojnë atë, por kur serveri di për mënyrat e ndryshme për të koduar një burim, ai mund të shikojë kokën dhe të dërgojë atë që preferon klienti.URL-ja eloquentjavascript.net/author është konfiguruar të përgjigjet me tekst të thjeshtë, HTML ose JSON, në varësi të kërkesës së klientit. Këto formate përcaktohen nga llojet e standardizuara të përmbajtjes tekst/i thjeshtë, tekst/html dhe aplikacion/json.
Paraqisni një kërkesë për të marrë të tre formatet e këtij burimi. Përdorni metodën setRequestHeader të objektit XMLHttpRequest për të vendosur kokën Prano në një nga llojet e kërkuara përmbajtjen. Sigurohuni që të vendosni kokën pas hapjes, por përpara dërgimit.
Së fundi, provoni të kërkoni përmbajtje si aplikacioni/ylbertë+unicorns dhe shikoni se çfarë ndodh.
Duke pritur për Premtime të Shumëfishta Konstruktori Promise ka një metodë të gjitha që, duke pasur parasysh një grup premtimesh, kthen një premtim që pret që të gjitha premtimet në grup të plotësohen. Më pas kthen një rezultat të suksesshëm dhe kthen një grup me rezultatet. Nëse ndonjë prej premtimeve në grup dështon, premtimi i përgjithshëm gjithashtu kthen dështimin (me vlerën e premtimit të dështuar nga grupi).Provoni diçka të ngjashme duke shkruar funksionin all.
Vini re se sapo të përfundojë një premtim (kur ai ose ka sukses ose dështon), ai nuk mund të dështojë ose të ketë sukses përsëri, dhe thirrjet e mëtejshme në funksion injorohen. Kjo mund ta bëjë më të lehtë trajtimin e gabimeve në premtimin tuaj.
Funksioni të gjitha(premtimet) ( ktheni Premtimin e ri (funksioni (sukses, dështon) ( // Kodi juaj. )); ) // Kodi i verifikimit. all().then(funksioni(array) ( console.log("Kjo duhet të jetë :", grup); )); funksioni së shpejti(val) ( kthimi i premtimit të ri(funksioni(sukses) ( setTimeout(funksion() ( sukses(val); ), Math.random() * 500); )); ) all().pastaj(funksion(array ) ( console.log ("Kjo duhet të jetë :", grup); )); funksioni fail() ( kthimi i premtimit të ri(funksioni(sukses, dështon) (fail(gabim i ri("boom")); )); ) all().then(funksion(array) (consol.log("Kjo është ku ne marrim nuk duhet "); ), funksion(gabim) ( if (error.message != "bang") console.log ("Burim i papritur:", gabim); ));
Prej shumë kohësh, shumë faqe kanë faqe dinamike, domethënë, ato përditësohen pa rindezje. Kjo arrihet duke thirrur serverin përmes JavaScript, në shumicën e rasteve, kërkesave POST dhe GET. Dhe pothuajse gjithmonë faqe të tilla përdorin Ajax për këtë. Dhe jo të gjithë e dinë (për fat të keq) se Ajax nuk është një gjuhë më vete, por thjesht një bibliotekë JavaScript. Përfundim: Ajax është i drejtë mënyrë e përshtatshme dërgoni kërkesa POST, por e gjithë kjo mund të bëhet pa ndihmën e saj. Kjo është se si të dërgoni kërkesat POST përmes JavaScript pa Ajax, do të mbuloj në këtë artikull.
Tani do të zgjidhim një problem klasik - përmbledhjen e dy numrave të specifikuar nga përdoruesi. Kjo do të thotë, ju dhe unë numërojmë 2 numra nga fushat e tekstit, i dërgojmë në server, marrim një përgjigje dhe i shfaqim në faqe. Dhe e gjithë kjo pa ringarkuar faqen.
Le të fillojmë me diçka të thjeshtë: shkrimin e kodit PHP:
Gjithçka këtu është elementare, kështu që as nuk do të komentoj. Tani vjen pjesa më e vështirë - ana e klientit:
/* Ky funksion krijon një objekt XMLHTTP me ndërshfletues */
funksioni getXmlHttp() (
var xmlhttp;
provoni (
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
) kap (e) (
provoni (
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
) kap (E) (
xmlhttp = false;
}
}
nëse (!xmlhttp && typeof XMLHttpRequest!="i pacaktuar") (
xmlhttp = new XMLHttpRequest();
}
ktheni xmlhttp;
}
përmbledhja e funksionit () (
var a = dokument.getElementById("a").vlera; // Lexoni vlerën e a
var b = dokument.getElementById("b").vlera; // Lexoni vlerën e b
var xmlhttp = getXmlHttp(); // Krijo një objekt XMLHTTP
xmlhttp.open("POST", "test.php", e vërtetë); // Hap një lidhje asinkrone
xmlhttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded"); // Dërgo kodimin
xmlhttp.send("a=" + encodeURIcomponent(a) + "&b=" + encodeURIcomponent(b)); // Dërgo një kërkesë POST
xmlhttp.onreadystatechange = funksion() ( // Në pritje të një përgjigje nga serveri
nëse (xmlhttp.readyState == 4) ( // Përgjigja mbërriti
if(xmlhttp.status == 200) ( // Serveri e ktheu kodin 200 (që është mirë)
document.getElementById("summa").innerHTML = xmlhttp.responseText; // Printoni përgjigjen e serverit
}
}
};
}
Shuma është:
Unë nuk do të komentoj për kodin HTML, pasi ai është plotësisht transparent. Por unë do të shtoj pak në JavaScript, pavarësisht komenteve të hollësishme. Së pari, funksioni getXmlHttp() është i përgjithshëm. Mund ta kopjoni me siguri në skriptet tuaja. Detyra e tij është të kthejë XMLHTTP të tillë në mënyrë që të funksionojë në çdo shfletues. Për shkak se opsioni më i popullarizuar është XMLHttpRequest() i ri, megjithatë, ai nuk funksionon për shembull në IE6. Opsionet e tjera nuk janë gjithashtu universale, kështu që këtu ne thjesht zgjedhim një opsion pune për çdo shfletues.
Unë gjithashtu kam shkruar në komente për " punë asinkrone". Ekziston edhe një opsion sinkron. I vetmi ndryshim është se në versionin sinkron, derisa të merret një përgjigje nga serveri, shfletuesi nuk do të funksionojë, thjesht do të varet. Është e vështirë për mua të dal me një detyrë ku kjo është e nevojshme, kështu që unë shkrova menjëherë opsion asinkron. Punon kështu: ne dërgojmë një kërkesë dhe presim një përgjigje, por shfletuesi nuk varet. Dhe kur të arrijë përgjigja (xmlhttp.readyState == 4 ), ne e përpunojmë menjëherë përgjigjen. Ky është versioni asinkron i punës, është pak më i komplikuar, por është i vetmi që duhet përdorur (përveç rasteve shumë të rralla).
Kështu dërgohen kërkesat POST përmes JavaScript. Siç mund ta shihni, ne nuk na duhej fare Ajax. Dhe unë rekomandoj fuqimisht që nëse keni vetëm disa kërkesa për të gjithë sitin, atëherë as mos mendoni të përdorni këtë bibliotekë të rëndë, por përdorni materialin në këtë artikull.
Një mësim në të cilin do të shikojmë krijimin e kërkesave të thjeshta asinkrone AJAX në server duke përdorur shembuj. Ne do të përdorim të dyja metodat GET dhe POST si metodë të transmetimit të kërkesës. Në server, ne do të përpunojmë kërkesat duke përdorur skriptet PHP.
Çfarë është një kërkesë asinkrone AJAX?Teknologjia AJAX përdoret kryesisht për të krijuar kërkesa asinkrone në server. Një kërkesë asinkrone është ajo që ekzekutohet në sfond dhe nuk ndërhyn në ndërveprimin e përdoruesit me faqen.
Kur dërgoni një kërkesë asinkrone, shfletuesi (faqja) nuk "ngrihet", d.m.th. ju mund të punoni me të si më parë. Por atëherë si e dini kur vjen përgjigja nga serveri? Për të përcaktuar këtë, ju duhet të monitoroni pronën ReadState të shfletuesit. Kjo pronë përmban një numër, vlera e të cilit mund të përdoret për të përcaktuar se në cilën fazë është kërkesa. Tabela e mëposhtme tregon vlerat kryesore të pronës readyState dhe gjendjet e tyre përkatëse.
Ato. Rezulton se ne duhet të gjurmojmë kur vlera e pronës readyState është e barabartë me 4. Kjo do të thotë që kërkesa e dërguar ka marrë një përgjigje nga serveri. Vlerat e mbetura përdoren mjaft rrallë në praktikë, dhe disa shfletues mund të mos i mbështesin ato.
Për të përcaktuar se në cilën fazë është kërkesa, duhet të përdorni ngjarjen onreadystatechange të objektit XMLHttpRequest. Kjo ngjarje ndodh sa herë që ndryshon vlera e vetive readyState. Prandaj, në mbajtësin e kësaj ngjarjeje (funksioni i paemërtuar ose i emërtuar), mund të shkruani veprime që do të kontrollojnë nëse kjo veti është e barabartë me 4 dhe nëse është e barabartë, atëherë, për shembull, shfaqni përgjigjen e serverit në faqe.
Krijimi i një asinkroni Kërkesa AJAX(metoda GET)Le të shohim krijimin e një kërkese asinkrone AJAX duke përdorur një shembull, i cili do të përshëndesë përdoruesin pasi të ngarkojë faqen dhe të shfaq adresën e tij IP.
Për ta bërë këtë, duhet të krijoni 2 skedarë në server në një direktori:
Le të shohim sekuencën e veprimeve që duhet të kryhen në anën e klientit (në kodin JavaScript):
Le të përgatisim të dhënat e nevojshme për të ekzekutuar kërkesën në server. Nëse nuk nevojiten të dhëna për të plotësuar kërkesën në server, atëherë ky hap mund të anashkalohet.
Le të krijojmë një variabël që do të përmbajë një shembull të objektit XHR (XMLHttpRequest).
Le të konfigurojmë kërkesën duke përdorur metodën open().
Parametrat e mëposhtëm janë specifikuar:
- Metoda me të cilën kërkesa do të dërgohet në server (GET, POST).
- URL-ja që do të përpunojë kërkesën në server.
- Lloji i kërkesës: sinkron (false) ose asinkron (i vërtetë).
- Emri i përdoruesit dhe fjalëkalimi nëse kërkohet.
Le të abonohemi në ngjarjen onreadystatechange të objektit XHR dhe të specifikojmë mbajtësin si një funksion anonim ose me emër. Pas kësaj, ne do të krijojmë kodin brenda këtij funksioni që do të kontrollojë statusin e përgjigjes dhe do të kryejë veprime të caktuara në faqe. Përgjigja që vjen nga serveri është gjithmonë në vetinë answerText.
Përveç kontrollit të vlerës së pronës së gatiState numër 4, mund të kontrolloni edhe vlerën e pronës statusore. Kjo pronë përcakton statusin e kërkesës. Nëse është e barabartë me 200, atëherë gjithçka është në rregull. Përndryshe, ndodhi një gabim (për shembull, 404 - URL nuk u gjet).
Le të dërgojmë një kërkesë në server duke përdorur metodën send().
Nëse përdorim metodën GET për të dërguar një kërkesë, atëherë kalojmë të dhënat te parametri këtë metodë Nuk ka nevojë. Ato dërgohen si pjesë e URL-së.
Nëse përdorim metodën POST për të dërguar një kërkesë, atëherë të dhënat duhet të kalojnë si parametër në metodën send(). Për më tepër, përpara se të telefononi këtë metodë, duhet të vendosni titullin Content-Type në mënyrë që serveri të dijë se në çfarë kodimi i ka ardhur kërkesa dhe mund ta deshifrojë atë.
Përmbajtja e elementit të skenarit:
// 2. Krijimi i variablit të kërkesës var request = new XMLHttpRequest(); // 3. Vendosja e kërkesës request.open("GET","processing.php",true); // 4. Abonohu në ngjarjen onreadystatechange dhe përpunoje atë duke përdorur funksionin anonim request.addEventListener("readystatechange", function() ( // nëse kërkesa është 4 dhe statusi i kërkesës është 200 (OK) nëse ((kërkesë. gatiState==4) && (request.status==200)) ( // për shembull, nxirrni objektin XHR në konsolën e shfletuesit console.log(kërkesë); // dhe përgjigjen (tekstin) që erdhi nga serveri në dritarja e alarmit console.log(request.responseText) ; // merrni një element me id = mirëpritur var welcome = document.getElementById("mirë se vini"); // zëvendësoni përmbajtjen e elementit me përgjigjen që erdhi nga mirëseardhja e serverit .innerHTML = request.responseText; ) )); // 5. Dërgimi i një kërkese në server request.send();
Si rezultat, skedari welcome.html do të ketë kodin e mëposhtëm:
Shembull i funksionimit të AJAX Shembull i punës AJAX window.addEventListener("load",function() ( var request = new XMLHttpRequest(); request.open("GET","processing.php",true); request.addEventListener(" readystatechange" , funksion() ( if ((request.readyState==4) && (request.status==200)) ( var welcome = document.getElementById("welcome"); welcome.innerHTML = request.responseText; ) ) Kërkesë.dërgoni();));
Në server (duke përdorur php):
