Si duket një kërkesë për të marrë. Përdorimi i metodave GET dhe POST

Në ditët e sotme, vetëm dy metoda HTTP përdoren më shpesh: GET dhe POST. Por doli që edhe midis këtyre dy "pishave" zhvilluesit e uebit arrijnë të humbasin. Ka një shpjegim për këtë: të dyja metodat mund të përdoren për të marrë të njëjtin rezultat. Por duhet të kujtojmë se përdorimi i pamenduar i cilësdo prej metodave mund të çojë në pasoja katastrofike, duke përfshirë ngarkesa të rënda në kanal dhe vrimat e sigurisë.

Për të shmangur këtë, mjafton thjesht të kuptoni më në detaje qëllimet dhe dallimet e këtyre metodave.

Nëse gërmoni në kuptimin e emrave të metodave, shumë do të bëhen më të qarta. GET (nga anglishtja për të marrë), d.m.th. duhet të përdoret për të kërkuar të dhëna. POST (nga anglishtja dërgoni me postë) - përdoret për të dërguar të dhëna në server. Gjithçka duket të jetë jashtëzakonisht e thjeshtë dhe e qartë. Por kushdo që dëshiron të zhvillojë uebsajte pak më të komplikuara se një faqe interneti me kartëvizitë me një formular reagimi, është më mirë ta njohë më mirë çështjen.

Kërkesa të sigurta dhe të pasigurta HTTP

Specifikimi HTTP 1.1 prezanton dy koncepte: kërkesë e sigurt dhe e pasigurt, ose më saktë, metodë.

Metodat e sigurta janë metoda që mund të kërkojnë vetëm informacion. Ata nuk mund të ndryshojnë burimin e kërkuar, as nuk mund të çojnë në rezultate të padëshirueshme për përdoruesin, të tjerët ose serverin. Shembuj të sigurt janë duke kërkuar kodin HTML të një faqeje interneti ose imazhi. Metodat e sigurta përfshijnë HEAD dhe GET.

Shënimi

Në realitet, zejtarët, natyrisht, mund të shkaktojnë dëm me kërkesat GET. Për shembull, unazat e pyetjeve.

Pyetjet e pasigurta, siç të gjithë e kanë hamendësuar tashmë, mund të çojnë në pasoja të këqija nëse ato përdoren përsëri. Kërkesa të tilla mund të ndryshojnë përmbajtjen e burimit që aksesohet. Shembuj të kërkesave të tilla: dërgimi i mesazheve, regjistrimi, pagesa online. Metodat e pasigurta përfshijnë POST, PUT, DELETE.

Metodat idempotente

Idempotenca është një veti e metodave që, me thirrje të shumta të përsëritura, do të japin të njëjtin rezultat, përveç rasteve kur informacioni është i vjetëruar. Kjo do të thotë që kur hyni në të njëjtën URL, të gjithë përdoruesit do të shohin të njëjtën faqe në internet, imazh, video, etj. Metodat GET, PUT, DELETE e kanë këtë veti.

Tani le të hedhim një vështrim më të afërt në vetë metodat GET dhe POST: le të shkruajmë një "përmbledhje" të shkurtër për secilën.

MARR

• projektuar për të marrë të dhëna nga serveri;
• trupi i kërkesës është bosh;
• përpunohet në anën e serverit më shpejt dhe me më pak konsum të burimeve të serverit për shkak të trupit bosh të kërkesës;
• transferimi i variablave ndodh në shiritin e adresave (kështu e sheh përdoruesi; teknikisht, të dhënat transmetohen në rreshtin e pyetjes) dhe për këtë arsye informacioni në lidhje me variablat dhe vlerat e tyre është i dukshëm (të dhënat nuk janë të mbrojtura);
• është në gjendje të transferojë një sasi të vogël të dhënash në server: ka kufizime në gjatësinë e URL-së, e cila varet nga shfletuesi, për shembull, IE6 = 2Kb. Zhvilluesit e Yahoo! rekomandojnë të përqendrohen në këtë numër;
• mund të transmetojë vetëm karaktere ASCII;
• një kërkesë e tillë mund të kopjohet dhe ruhet (për shembull, në faqerojtësit);
• kërkesa mund të ruhet në memorie (kjo mund të kontrollohet);
• për të reduktuar më tej ngarkesën në kanal dhe server, ofrohen kërkesa të kushtëzuara dhe të pjesshme;
• nuk e prish lidhjen HTTP (nëse modaliteti keepAlive është i aktivizuar në server).

POST

• të destinuara për dërgimin e të dhënave në server;
• transferimi i të dhënave ndodh në trupin e kërkesës;
• Përpunimi nga serveri është më i ngadalshëm dhe "më i rëndë" se GET, sepse përveç titujve, trupi i kërkesës duhet të analizohet;
• të aftë për të transmetuar sasi të mëdha të dhënash;
• të aftë për të transferuar skedarë;
• një faqe e krijuar nga metoda POST nuk mund të ruhet si faqerojtës;
• prish lidhjen HTTP;
• Për të transmetuar qoftë edhe një sasi shumë të vogël informacioni, shumica e shfletuesve dërgojnë të paktën dy paketa TCP: një kokë dhe më pas një pjesë të kërkesës.

Rezulton se këto dy metoda nuk janë aq të ngjashme. Përdorimi i njërës ose tjetrës duhet të përcaktohet nga detyra në fjalë, dhe jo nga fakti që GET përdoret si parazgjedhje ose është më e lehtë për të punuar me të. GET, natyrisht, është një opsion më i mirë në shumicën e rasteve, veçanërisht kur ndërtoni AJAX të shpejtë, por mos harroni për disavantazhet e tij. Për veten time, bëra një shënim të thjeshtë algoritmi për zgjedhjen e një metode.

Ky postim është një përgjigje për një pyetje të bërë në një nga artikujt e mi.

Në këtë artikull dua t'ju tregoj se cilat janë metodat HTTP GET/POST/PUT/DELETE dhe të tjera, pse u shpikën dhe si t'i përdorni ato në përputhje me REST.

HTTP

Pra, cili është një nga protokollet kryesore të internetit? Unë do t'i dërgoj pedantët në RFC2616, dhe do t'i tregoj të tjerët në mënyrë njerëzore :)

Ky protokoll përshkruan ndërveprimin ndërmjet dy kompjuterëve (klientit dhe serverit), i ndërtuar mbi bazën e mesazheve të quajtura kërkesë (Kërkesë) dhe përgjigje (Përgjigje). Çdo mesazh përbëhet nga tre pjesë: një linjë fillestare, kokë dhe një trup. Në këtë rast, kërkohet vetëm vija e fillimit.

Linjat e fillimit për kërkesën dhe përgjigjen kanë formate të ndryshme - ne jemi të interesuar vetëm për vijën fillestare të kërkesës, e cila duket si kjo:

METODA URI HTTP/ VERSION ,

Aty ku METHOD është metoda e kërkesës HTTP, URI është identifikuesi i burimit, VERSIONI është versioni i protokollit (aktualisht versioni 1.1 është aktual).

Titujt janë një koleksion çiftesh emër-vlerë të ndara me dy pika. Titujt përcjellin informacione të ndryshme të shërbimit: kodimin e mesazhit, emrin dhe versionin e shfletuesit, adresën nga erdhi klienti (Referruesi) dhe kështu me radhë.

Trupi i mesazhit është të dhënat aktuale që transmetohen. Në përgjigje, të dhënat e transmetuara janë zakonisht faqja HTML që kërkoi shfletuesi, dhe në kërkesë, për shembull, në trupin e mesazhit, transmetohet përmbajtja e skedarëve të ngarkuar në server. Por, si rregull, nuk ka fare organ mesazhi në kërkesë.

Shembull i ndërveprimit HTTP

Le të shohim një shembull.

Kërkesë:
GET /index.php HTTP/1.1 Pritësi: shembull.com Agjenti i përdoruesit: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Prano: tekst/html Lidhja: mbyll
Rreshti i parë është linja e pyetjes, pjesa tjetër janë kokë; trupi i mesazhit mungon

Përgjigje:
HTTP/1.0 200 OK Serveri: nginx/0.6.31 Përmbajtja-Gjuha: ru Lloji i Përmbajtjes: tekst/html; charset=utf-8 Përmbajtja-Gjatësia: 1234 Lidhja: mbyll ... VETË FAQJA HTML...

Burimet dhe metodat

Le të kthehemi në vijën fillestare të kërkesës dhe të kujtojmë se ajo përmban një parametër të tillë si URI. Kjo qëndron për Uniform Resource Identifier - një identifikues uniform i burimit. Një burim është, si rregull, një skedar në server (një shembull URI në këtë rast është "/styles.css"), por në përgjithësi një burim mund të jetë gjithashtu një objekt abstrakt ("/blogs/webdev/" - pikë në zhvillimin e bllokut "Ueb"" dhe jo në një skedar specifik).

Lloji i kërkesës HTTP (i quajtur edhe metoda HTTP) i tregon serverit se çfarë veprimi duam të kryejmë në burim. Fillimisht (në fillim të viteve '90) supozohej se klienti mund të dëshironte vetëm një gjë nga një burim - ta merrte atë, por tani duke përdorur protokollin HTTP mund të krijoni postime, të modifikoni një profil, të fshini mesazhe dhe shumë më tepër. Dhe këto veprime janë të vështira për t'u kombinuar me termin "faturë".

Për të dalluar veprimet nga burimet në nivelin e metodave HTTP, u shpikën opsionet e mëposhtme:

• GET - marrja e një burimi
• POST - krijimi i burimeve
• PUT - përditësimi i burimeve
• FSHIJE - fshirja e një burimi

Ju lutemi vini re se specifikimi HTTP nuk kërkon që serveri të kuptojë të gjitha metodat (nga të cilat në fakt ka shumë më shumë se 4) - kërkohet vetëm GET, dhe gjithashtu nuk i tregon serverit se çfarë duhet të bëjë kur merr një kërkesë me një kërkesë të veçantë. metodë. Kjo do të thotë se serveri në përgjigje të kërkesës DELETE /index.php HTTP/1.1 nuk është i detyruar të fshini faqen index.php në server, njësoj si për një kërkesë GET /index.php HTTP/1.1 nuk është i detyruar të të kthejë faqen index.php tek ju, mund ta fshijë për shembull :)

REST hyn në lojë

REST (Representational State Transfer) është një term i prezantuar në vitin 2000 nga Roy Fielding, një nga zhvilluesit e protokollit HTTP, si emri i një grupi parimesh për ndërtimin e aplikacioneve në ueb. Në përgjithësi, REST mbulon një zonë më të gjerë se HTTP - mund të përdoret gjithashtu në rrjete të tjera me protokolle të tjera. REST përshkruan parimet e ndërveprimit midis klientit dhe serverit, bazuar në konceptet e "burimit" dhe "foljes" (mund të kuptohet si temë dhe kallëzues). Në rastin e HTTP, burimi identifikohet nga URI i tij, dhe folja është metoda HTTP.

REST sugjeron braktisjen e përdorimit të së njëjtës URI për burime të ndryshme (d.m.th., adresat e dy artikujve të ndryshëm si /index.php?article_id=10 dhe /index.php?article_id=20 - kjo nuk është një mënyrë REST) ​​dhe duke përdorur metoda të ndryshme HTTP për veprime të ndryshme. Kjo do të thotë, një aplikacion në internet i shkruar duke përdorur qasjen REST do të fshijë një burim kur e akseson atë me metodën HTTP DELETE (natyrisht, kjo nuk do të thotë që është e nevojshme të jepet mundësia për të fshirë gjithçka dhe të gjithë, por ndonjë kërkesa për fshirje e aplikacionit duhet të përdorë metodën HTTP DELETE).

REST u jep programuesve mundësinë për të shkruar aplikacione ueb të standardizuara dhe pak më të bukura se më parë. Duke përdorur REST, URI për të shtuar një përdorues të ri nuk do të jetë /user.php?action=create (metoda GET/POST), por thjesht /user.php (metoda strikte POST).

Si rezultat, duke kombinuar specifikimet ekzistuese HTTP dhe qasjen REST, metoda të ndryshme HTTP më në fund kanë kuptim. GET - kthen një burim, POST - krijon një të ri, PUT - përditëson një ekzistues, DELETE - e fshin atë.

Probleme?

Po, ka një problem të vogël me përdorimin e REST në praktikë. Ky problem quhet HTML.

Kërkesat PUT/DELETE mund të dërgohen duke përdorur XMLHttpRequest, duke kontaktuar serverin manualisht (të themi, nëpërmjet curl ose edhe nëpërmjet telnet), por nuk mund të bëni një formë HTML që dërgon një kërkesë të plotë PUT/DELETE.

Çështja është se specifikimi HTML nuk ju lejon të krijoni forma që dërgojnë të dhëna të tjera përveçse nëpërmjet GET ose POST. Prandaj, për të punuar normalisht me metoda të tjera, duhet t'i imitoni ato në mënyrë artificiale. Për shembull, në Rack (mekanizmi në bazë të të cilit Ruby ndërvepron me serverin në internet; Rails, Merb dhe korniza të tjera Ruby bëhen duke përdorur Rack), mund të shtoni një fushë të fshehur në formular me emrin "_method", dhe specifikoni emrin e metodës si vlerë (p.sh. "PUT") - në këtë rast, një kërkesë POST do të dërgohet, por Rack do të jetë në gjendje të pretendojë se ka marrë një PUT dhe jo një POST.

Sot doja të thellohesha pak në gjëra primitive dhe të përshkruaj atë që mund të gjendet në World Wide Web në sasi të mëdha dhe pa shumë vështirësi. Do të flasim praktikisht për të shenjtën e protokollit HTTP: kërkesat POST dhe GET.

Shumë do të pyesin pse? Unë do të përgjigjem shkurt dhe qartë: jo të gjithë e dinë se çfarë është dhe pse është e nevojshme, dhe ata që duan të mësojnë për të (ndërsa kuptojnë pak në fushën e IT) shpesh nuk mund të kuptojnë se çfarë shkruhet në shumë e shumë artikuj kushtuar kësaj. temë. Do të përpiqem të shpjegoj me gishta se çfarë janë kërkesat POST dhe GET dhe për çfarë përdoren ato.
Pra, le të fillojmë udhëtimin tonë në një përrallë ...
Nëse jeni duke e lexuar këtë mesazh, atëherë të paktën e dini se si duket interneti dhe çfarë është një faqe interneti. Duke lënë jashtë të gjitha ndërlikimet e punës së World Wide Web, ne do të operojmë me koncepte të tilla si përdorues dhe sajt. Çfarëdo që mund të thuhet, këto dy entitete duhet disi të ndërveprojnë me njëri-tjetrin. Për shembull, njerëzit komunikojnë me njëri-tjetrin përmes gjesteve, emocioneve dhe të folurit, kafshët nxjerrin disa tinguj, por çfarë ndodh kur një person dhe një burim në internet "komunikojnë"? Këtu kemi një rast shkëmbimi informacioni, i cili mund të transferohet në një bisedë njerëzore “Pyetje-Përgjigje”. Për më tepër, si përdoruesi ashtu edhe faqja mund të bëjnë pyetje dhe përgjigje. Kur flasim për një faqe interneti, pyetjet dhe përgjigjet e saj, si rregull, shprehen gjithmonë në formën e një faqe interneti me një tekst ose një tjetër. Kur bëhet fjalë për përdoruesin, atëherë gjithçka ndodh falë kërkesave GET dhe POST (sigurisht jo vetëm, por po flasim për to).

Kështu, zbuluam se objektet tona tematike janë të nevojshme për të "komunikuar" me faqet. Për më tepër, të dyja kërkesat GET dhe POST mund të përdoren për t'i "bërë pyetje" sajtit dhe për t'u "përgjigjur" atyre. Si janë të ndryshëm? Gjithçka është mjaft e thjeshtë. Sidoqoftë, për të shpjeguar ndryshimet, do të duhet të shqyrtojmë një shembull, për të cilin do të marrim faqen e një plani të dyqanit në internet.
Ju ndoshta keni vënë re shpesh kur po kërkoni diçka në dyqanet në internet që kur kërkoni duke përdorur filtra, adresa e faqes kthehet nga "http://magaazin.ru" e bukur në "http://magaazin.ru/?kategoria" e frikshme = këpucë dhe madhësia = 38". Pra, çdo gjë që vjen pas simbolit '?' është kërkesa juaj GET ndaj sajtit, dhe për të qenë plotësisht i saktë, në këtë rast ju po pyesni faqen se çfarë ka në kategorinë "Këpucët" nga madhësitë "38" (ky shembull) është hequr nga koka ime, në realitet gjithçka mund të mos duket aq e qartë). Si rezultat, ne mund të bëjmë vetë pyetje duke i treguar ato në shiritin e adresave të faqes. Natyrisht, kjo metodë ka disa disavantazhe. Së pari, kushdo që është pranë përdoruesit në kompjuter mund të spiunojë lehtësisht të gjitha të dhënat, kështu që përdorimi i këtij lloji të kërkesës për të transferuar fjalëkalime është shumë i padëshirueshëm. Së dyti, ka një kufizim në gjatësinë e vargut që mund të transferohet nga fusha e adresës së faqes, që do të thotë se nuk do të jetë e mundur të transferohen shumë të dhëna. Sidoqoftë, përparësia e padyshimtë e përdorimit të kërkesave GET është lehtësia e përdorimit dhe aftësia për të kërkuar shpejt faqen, e cila është veçanërisht e dobishme gjatë zhvillimit, por kjo është një histori tjetër...
Tani le të flasim për kërkesat POST. Lexuesit e zgjuar mund të kenë kuptuar se ndryshimi kryesor midis kësaj kërkese dhe homologut të saj është fshehtësia e të dhënave të transmetuara. Nëse marrim parasysh një dyqan online, një shembull i mrekullueshëm ku përdoret një kërkesë POST është regjistrimi në sit. Faqja kërkon të dhënat tuaja, ju i plotësoni këto të dhëna dhe kur klikoni në butonin “Regjistrim” dërgoni përgjigjen tuaj. Për më tepër, këto të dhëna nuk do të shfaqen në asnjë mënyrë nga jashtë. Vlen gjithashtu të theksohet se mund të kërkohet një sasi mjaft e madhe informacioni - por kërkesa POST nuk ka kufizime. Epo, nëse prekni minusin, atëherë një kërkesë e tillë nuk mund të gjenerohet shpejt. Ju nuk mund ta bëni këtë pa aftësi të veçanta. Edhe pse në realitet gjithçka nuk është aq e vështirë, por përsëri, kjo është një histori tjetër.
Le të përmbledhim. Kërkesat POST dhe GET nevojiten për "komunikim" midis përdoruesit dhe sajtit. Ato janë në thelb pothuajse e kundërta e njëra-tjetrës. Përdorimi i disa llojeve të pyetjeve varet nga situata specifike dhe përdorimi i vetëm një lloji të pyetjeve është jashtëzakonisht i papërshtatshëm.

Ky postim ka për qëllim të shpjegojë parimet e transmetimit të të dhënave në internet duke përdorur dy metoda kryesore: GET dhe POST. E shkrova si një shtesë të udhëzimeve për gjeneratorin e orarit të ndërrimeve për ata që nuk kanë gjasa të jenë të interesuar për detajet ☺.

Shkoni në adresën e mëposhtme (kjo është për një shpjegim vizual): http://calendarin.net/calendar.php?year=2016 Kushtojini vëmendje shiritit të adresave të shfletuesit: calendarin.net/calendar.php ?vit=2016 Skedari kryesor emërtohet i ndjekur nga një pikëpyetje (?) dhe një parametër "viti" me vlerën "2016". Pra, gjithçka që pason pikëpyetjen është një kërkesë GET. Është e thjeshtë. Për të kaluar më shumë se një parametër, ata duhet të ndahen me një ampersand (&). Shembull: calendarin.net/calendar.php ?viti=2016&display=ditët-punë-dhe-ditët e pushimit

Skedari kryesor është ende i emërtuar, i ndjekur nga një pikëpyetje (?), më pas një parametër "vit" me vlerën "2016", më pas një ampersand (&), më pas një parametër "shfaqje" me vlerën "ditët e punës- dhe-ditë” -off”.

Parametrat GET mund të ndryshohen drejtpërdrejt në shiritin e adresave të shfletuesit. Për shembull, ndryshimi i vlerës "2016" në "2017" dhe shtypja e tastit do t'ju çojë në kalendarin për 2017.

Ky është një transferim i fshehur i të dhënave (adresa e faqes nuk ndryshon); domethënë, ju mund të shihni vetëm atë që u transferua duke përdorur një program (skript). Për shembull, në mjetin e mëposhtëm për numërimin e karaktereve në tekst, të dhënat origjinale transmetohen duke përdorur metodën POST: http://usefulonlinetools.com/free/character-counter.php

Nëse keni ndonjë pyetje, komente dhe emaili im është në shërbimin tuaj.

Përveç metodës GET, të cilën e diskutuam në postimin e mëparshëm, ekziston një metodë tjetër për dërgimin e një kërkese përmes protokollit HTTP - metoda POST. Metoda POST përdoret gjithashtu shumë shpesh në praktikë.

Nëse, për të kontaktuar serverin duke përdorur metodën GET, na duhej vetëm të shkruanim një kërkesë në URL, atëherë në metodën POST gjithçka funksionon në një parim tjetër.

Për të ekzekutuar këtë lloj kërkese, duhet të klikojmë në butonin me atributin type="submit", i cili ndodhet në faqen e internetit. Ju lutemi vini re se ky buton ndodhet në element

, e cila ka atributin e metodës të vendosur në postim.

Merrni parasysh këtë kod HTML:

Fut tekstin:

Nëse përdoruesi fut një tekst në fushën e tekstit dhe klikon në butonin "Dërgo", ndryshorja e tekstit do të dërgohet në server me vlerën e përmbajtjes që përdoruesi ka futur.

Kërkesat POST dhe GET me fjalë të thjeshta

Kjo variabël do të dërgohet duke përdorur metodën POST.

Nëse e shkruani formularin si kjo:

Pastaj të dhënat do të dërgohen duke përdorur metodën GET.

Nëse, në rastin e një kërkese GET, sasia e të dhënave që mund të transferonim ishte e kufizuar nga gjatësia e shiritit të adresave të shfletuesit, atëherë në rastin e një kërkese POST, nuk ka një kufizim të tillë dhe ne mund të transferojmë shuma të konsiderueshme të informacionit.

Një tjetër ndryshim midis metodës POST dhe metodës GET është se metoda POST fsheh të gjitha variablat që kalon dhe vlerat e tyre në trupin e saj (Entity-Body). Në rastin e metodës GET, ato u ruajtën në vargun e kërkesës (Kërkesë-URI).

Këtu është një shembull i një kërkese të bërë duke përdorur metodën POST:

POST / HTTP/1.0\r\n
Pritësi: www.site.ru\r\n
Referues: http://www.site.ru/index.html\r\n
Cookie: të ardhura=1\r\n
Lloji i përmbajtjes: aplikacioni/x-www-form-urlencoded\r\n
Gjatësia e përmbajtjes: 35\r\n
\r\n
login=Dima&fjalëkalimi=12345

Kështu, duke transmetuar të dhëna duke përdorur metodën POST, do të jetë shumë më e vështirë për një sulmues që t'i përgjojë ato, sepse ato janë të fshehura nga pamja e drejtpërdrejtë, kështu që metoda POST e transmetimit të të dhënave konsiderohet një metodë më e sigurt.

Përveç kësaj, duke përdorur metodën POST mund të transferoni jo vetëm tekst, por edhe të dhëna multimediale (foto, audio, video). Ekziston një parametër i veçantë Content-Type që përcakton llojin e informacionit që duhet të transmetohet.

Dhe së fundi, për të marrë të dhënat që janë transmetuar me këtë metodë në server, përdoret ndryshorja POST.

Këtu është një shembull i përpunimit në PHP:

echo $_POST['tekst'];
?>

Në postimin e fundit, vendosëm që shfletuesi (klienti) të dërgojë kërkesa HTTP në server dhe serveri t'i dërgojë përgjigjet HTTP klientit. Këto kërkesa dhe përgjigje janë të formatuara sipas rregullave të caktuara. Ka diçka si një sintaksë, si dhe në çfarë sekuence duhet të shkruhet. Duhet të ketë një strukturë të përcaktuar rreptësisht.

Le të hedhim një vështrim më të afërt në këtë strukturë me të cilën kërkesat dhe përgjigjet ndërtohen në protokollin HTTP.

Një kërkesë HTTP përbëhet nga tre pjesë kryesore, të cilat shfaqen në rendin e renditur më poshtë. Midis titujve dhe trupit të mesazhit ka një rresht bosh (si ndarës), ai përfaqëson një karakter të furnizimit të linjës.

Varg bosh (kufizues)

Posto dhe Merr kërkesa, cili është ndryshimi midis tyre dhe cili është më i mirë dhe për çfarë qëllimesh?

trupi i mesazhit (Entity Body) – parametër opsional

Vargu i pyetjes– specifikon metodën e transferimit, URL-në që do të aksesohet dhe versionin e protokollit HTTP.

Titujt– përshkruani tërësinë e mesazheve, transmetoni parametra të ndryshëm dhe informacione dhe informacione të tjera.

trupi i mesazhit- këto janë vetë të dhënat që transmetohen në kërkesë. Trupi i mesazhit është një parametër opsional dhe mund të mungojë.

Kur marrim një kërkesë për përgjigje nga serveri, trupi i mesazhit është më shpesh përmbajtja e faqes së internetit. Por, kur bëni kërkesa në server, ai ndonjëherë mund të jetë i pranishëm, për shembull, kur transferojmë të dhënat që kemi plotësuar në formularin e reagimit në server.

Ne do të shikojmë çdo element të kërkesës në më shumë detaje në shënimet e mëposhtme.

Le të shqyrtojmë, për shembull, një kërkesë reale për serverin. Unë e kam theksuar secilën pjesë të kërkesës me një ngjyrë të ndryshme: vija e kërkesës është e gjelbër, titujt janë portokalli dhe trupi i mesazhit është blu.

Kërkesa e shfletuesit:

Pritësi: webgyry.info

Cookie: wp-settings

Lidhja: mbaj gjallë

Në shembullin e mëposhtëm, trupi i mesazhit është tashmë i pranishëm.

Përgjigja e serverit:

Lloji i përmbajtjes: tekst/html; charset=UTF-8

Transferimi-Enkodimi: i copëtuar

Lidhja: mbaj gjallë

Keep-Alive: timeout=5

X-Pingback: //webgyry.info/xmlrpc.php

Këto janë mesazhet e shkëmbyera ndërmjet klientit dhe serverit nëpërmjet HTTP.

Nga rruga, a doni të zbuloni nëse ka ndonjë pikë në ndonjë element në faqen tuaj të internetit duke përdorur "qëllimet" e Yandex Metrics dhe Google Analytics?

Hiqni atë që nuk funksionon, shtoni atë që funksionon dhe dyfishoni të ardhurat tuaja.

Kurs për përcaktimin e qëllimeve të Yandex Metrics..

Kurs për përcaktimin e qëllimeve të Google Analytics..

Klienti HTTP dërgon një kërkesë në server në formën e një mesazhi kërkese, i cili ka formatin e mëposhtëm:

• Vargu i pyetjes (kërkohet)
• Titulli (element opsional)
• Varg bosh (kërkohet)
• Trupi i mesazhit (element opsional)

Le të shohim secilin prej këtyre elementeve veç e veç.

Vargu i pyetjes

Linja e kërkesës fillon me një shenjë metode, e ndjekur nga URI e kërkesës dhe versioni i protokollit. Elementet ndahen nga njëri-tjetri me hapësira:

Le ta shohim këtë element në më shumë detaje.

Metoda e kërkesës

Ky element specifikon një metodë që duhet të thirret në anën e serverit në URI të specifikuar.

Ekzistojnë tetë metoda në HTTP:

• KOKË
  Përdoret për të marrë statusin dhe vargun e kokës nga serveri nga URI. Nuk ndryshon të dhënat.
• MARR
  Përdoret për të marrë të dhëna nga serveri në URI të specifikuar. Nuk ndryshon të dhënat.
• POST
  Përdoret për të dërguar të dhëna në server (siç janë informacionet e zhvilluesit, etj.) duke përdorur forma HTML.
• VENDOSJE
  Zëvendëson të gjitha të dhënat e mëparshme në burim me të dhënat e reja të ngarkuara.
• FSHIJE
  Fshin të gjitha të dhënat aktuale në burimin e specifikuar nga URI.
• LIDH
  Krijon një lidhje tuneli me serverin në URI të specifikuar.
• OPSIONE
  Përshkruan vetitë e lidhjes për burimin e specifikuar.
• GJURME
  Ofron një mesazh që përmban një gjurmë kthimi të vendndodhjes së burimit të specifikuar në URI.

Kërko URI

URI (Uniform Resource Identifier) ​​është identifikuesi i burimit tek i cili është dërguar kërkesa. Më poshtë është formati URI më i përdorur:

‘*’ përdoret kur një kërkesë HTTP nuk lidhet me një burim specifik, por me një server. Përdoret vetëm kur metoda nuk ka nevojë të zbatohet në një burim. Për shembull,

absoluteURI përdoret kur një kërkesë HTTP bëhet në një përfaqësues. Përfaqësuesit i kërkohet të kalojë kërkesën nga memoria e disponueshme dhe kthen një përgjigje. Për shembull:

shtegu_absolut | burimi më të përdorura.

Mësoni të punoni me kërkesat GET dhe POST

Kërkohet një burim specifik në një server specifik. Për shembull, një klient dëshiron të marrë një burim nga një server përmes portit 80. Adresa e burimit është "www.proselyte.net" dhe dërgon kërkesën e mëposhtme:

Pyetje për fushat e kokës

Fushat e kokës lejojnë klientin të kalojë informacion shtesë në lidhje me kërkesën dhe veten në server. Këto fusha veprojnë si modifikues të pyetjeve.

Më poshtë është një listë e fushave më të rëndësishme të kokës që mund të përdoren:

• Prano-Charset
• Prano-Enkodim
• Prano-Gjuha
• Autorizimi
• presin
• Nëse-Match
• Nëse-Modifikuar-Që
• Nëse-Asnjë-Përputhje
• Nëse-Raga
• Nëse-Unmodifikuar-Që
• Gama
• Referues
• Përdorues-Agjent

Nëse duam të implementojmë klientin tonë dhe serverin tonë të internetit, atëherë mund të krijojmë fushat tona të kokës.

Shembull i kërkesës HTTP

Kjo përfundon studimin tonë të kërkesave HTTP.
Në artikullin tjetër do të shikojmë përgjigjet HTTP.

Një nga mënyrat se si mund të dërgoni një kërkesë HTTP në një server është me metodën GET. Kjo metodë është më e zakonshme dhe kërkesat për server ndodhin më shpesh duke përdorur atë.

Mënyra më e lehtë për të krijuar një kërkesë GET është të shkruani URL-në në shiritin e adresave të shfletuesit tuaj.

Shfletuesi do t'i dërgojë serverit afërsisht informacionin e mëposhtëm:

GET / HTTP/1.1
Pritësi: webgyry.info
Agjenti i përdoruesit: Mozilla/5.0 (Windows NT 6.1; rv:18.0) Gecko/20100101 Firefox/18.0
Prano: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Prano-Gjuha: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Prano-Enkodimi: gzip, deflate
Cookie: wp-settings
Lidhja: mbaj gjallë

Kërkesa përbëhet nga dy pjesë:

1. Linja e Kërkesës

2. Titujt e mesazheve

Vini re se një kërkesë GET nuk ka një trup mesazhi. Por kjo nuk do të thotë që me ndihmën e tij ne nuk mund të transmetojmë asnjë informacion në server.

Dallimi midis metodave GET dhe POST

Kjo mund të bëhet duke përdorur parametra të veçantë GET.

Për të shtuar parametrat GET në një kërkesë, duhet të shtoni një “?” në fund të URL-së. dhe më pas filloni t'i pyesni sipas rregullit të mëposhtëm:

parametri_emri1=parametri_vlera1¶metri_emri2=parametri_vlera2&…

Ndarësi midis parametrave është shenja "&".

Për shembull, nëse duam të kalojmë dy vlera në server, emrin e përdoruesit dhe moshën e tij, atëherë kjo mund të bëhet me rreshtin e mëposhtëm:

http://site.ru/page.php?name=dima&age=27

Kur kjo kërkesë ekzekutohet, të dhënat përfundojnë në të ashtuquajturën ndryshore të mjedisit QUERY_STRING, nga e cila mund të merren në server duke përdorur një gjuhë programimi në ueb nga ana e serverit.

Këtu është një shembull se si kjo mund të bëhet në PHP.

jehonë "Emri juaj: " . $_GET["emri"] . "
»;
jehonë "Mosha juaj: " . $_GET["mosha"] . "
»;
?>

Konstruksioni $_GET[“parameter_name”] ju lejon të shfaqni vlerën e parametrit të kaluar.

Si rezultat i ekzekutimit të këtij kodi në shfletues, do të shfaqet sa vijon:

Emri juaj: dima
Mosha juaj: 27

Ne gjithashtu bëjmë një kërkesë në server duke përdorur metodën GET.

Metoda e parë për të kryer një kërkesë PHP POST është përdorimi i file_get_contents. Metoda e dytë do të përdorë fread në kombinim me disa funksione të tjera. Të dy opsionet përdorin funksionin stream_context_create për të plotësuar fushat e kërkuara të kokës së kërkesës.

Shpjegimi i kodit

Ndryshorja $sPD përmban të dhënat që do të transferohen. Duhet të jetë në formatin e vargut të kërkesës HTTP, kështu që disa karaktere speciale duhet të kodohen.

Si në funksionin file_get_contents ashtu edhe në funksionin fread kemi dy parametra të rinj. E para është use_include_path. Meqenëse po bëjmë një kërkesë HTTP, ajo do të jetë false në të dy shembujt. Kur vendoset në true për të lexuar një burim lokal, funksioni do të kërkojë skedarin në include_path.

Parametri i dytë është konteksti, i cili është i mbushur me vlerën e kthimit të stream_context_create, e cila merr vlerën e grupit $aHTTP.

Përdorimi i file_get_contents për të bërë kërkesa POST

Për të dërguar një kërkesë POST duke përdorur file_get_contents në PHP, duhet të përdorni stream_context_create për të plotësuar manualisht fushat e kokës dhe të specifikoni se cilin "mbështjellës" të përdorni - në këtë rast HTTP:

$sURL = "http://brugbart.com/Examples/http-post.php"; // POST URL $sPD = "emri=Jacob&bench=150"; // Të dhënat POST $aHTTP = grup ("http" => // Mbështjellësi që do të përdoret array("metod" => "POST", // Metoda e kërkesës // Titujt e kërkesës vendosen poshtë "header" => "Përmbajtja - lloji: aplikacioni/x-www-form-urlencoded", "content" => $sPD)); $kontekst = stream_context_create($aHTTP); $përmbajtje = file_get_contents ($sURL, false, $context); jehonë $përmbajtje;

Përdorimi i fread për të kryer kërkesat POST

Ju mund të përdorni funksionin fread për të bërë kërkesa POST. Shembulli i mëposhtëm përdor stream_context_create për të kompozuar titujt e nevojshëm të kërkesës HTTP:

$sURL = "http://brugbart.com/Examples/http-post.php"; // POST URL $sPD = "emri=Jacob&bench=150"; // Të dhënat POST $aHTTP = grup ("http" => // Mbështjellësi që do të përdoret array("metod" => "POST", // Metoda e kërkesës // Titujt e kërkesës vendosen poshtë "header" => "Përmbajtja - lloji: aplikacioni/x-www-form-urlencoded", "content" => $sPD)); $kontekst = stream_context_create($aHTTP); $handle = fopen($sURL, "r", false, $context); $contents = ""; ndërsa (!feof($handle)) ( $përmbajtje .= fread($handle, 8192); ) fclose($handle); jehonë $përmbajtje;

Bërja e kërkesave GET me PHP

Tani do të fokusohemi në përdorimin e fread dhe file_get_contents për të shkarkuar përmbajtje nga interneti nëpërmjet HTTP dhe HTTPS. Për të përdorur metodat e përshkruara në këtë artikull, duhet të aktivizoni opsionin fopen wrappers. Për ta bërë këtë, duhet të vendosni parametrin allow_url_fopen në On në skedarin php.ini.

Kryerja e kërkesave POST dhe GET në PHP përdoret për të hyrë në faqet e internetit, për të marrë përmbajtjen e faqeve të internetit ose për të kontrolluar për versione të reja të aplikacioneve. Ne do të trajtojmë se si të bëjmë kërkesa të thjeshta HTTP.

Përdorimi i fread për të shkarkuar ose marrë skedarë përmes Internetit

Mos harroni se leximi i faqes në internet është i kufizuar në pjesën e aksesueshme të paketës. Kështu që ju duhet të përdorni funksionin stream_get_contents ( ngjashëm me file_get_contents) ose një lak për të lexuar përmbajtjen në copa më të vogla derisa të arrihet fundi i skedarit:

Në këtë rast të përpunimit të një kërkese PHP POST, argumenti i fundit i funksionit fread është i barabartë me madhësinë e fragmentit. Në përgjithësi nuk duhet të jetë më i madh se 8192 ( 8*1024 ).

Mbani në mend se mund të jetë më i madh ose më i vogël dhe gjithashtu mund të kufizohet nga cilësimet e sistemit në të cilin po ekzekutohet PHP.

Përdorimi i file_get_contents për të marrë URL-në e një sajti

Është edhe më e lehtë të përdoret kjo metodë kur lexoni një skedar përmes HTTP, pasi nuk keni pse të shqetësoheni për leximin në copa - gjithçka trajtohet në PHP.

Përkthimi i artikullit “Bërja e kërkesave POST me PHP” u përgatit nga ekipi miqësor i projektit