Kërkesat HTTP GET, POST dhe PUT. Mësoni të punoni me kërkesat GET dhe POST

11.08.2019 Lajme

Përdorimi i metodave GET dhe POST në PHP është i vështirë të mbivlerësohet, pasi këto metoda gjenden pothuajse në çdo faqe. Para se të studioni materialin e përshkruar më poshtë, ju këshilloj të njiheni me etiketën html

... Le të hedhim një vështrim në secilën prej këtyre metodave në detaje.

Metoda GET

Metoda GET përdor një varg URL për të kaluar të dhënat. Ju mund të keni vënë re URL të gjata dhe të paqarta. Për shembull: funksion.php?hyrje = Alex & email = dezyakin... Në këtë rast të dhënat përpunohen në funksion.php. Pas pikëpyetjes "?" Ekziston një numërim i parametrave të transmetuar (parametri ndahet me shenjën "&") me vlerat: parametrit të hyrjes i caktohet vlera Alex, dhe ndryshores së emailit është dezyakin. Të dhënat do të ruhen në grupin superglobal $ _GET. Një shembull i përdorimit të metodës GET është paraqitur më poshtë:

Identifikohu: Email: Duke përdorur grupin superglobal $ _GET, ne shfaqim vlerat e pranuara:* / jehonë "
login = ". $ _GET [" login "]; jehonë"
email = ". $ _MERRNI [" email "];?>

Vini re se si lexojmë vlerat nga grupi superglobal $ _GET: $ _MERRNI ["emri_ndryshore"]... Në shembullin tonë, emrat e variablave u deklaruan në formën (emri = login dhe emri = email).

Këshilla:
Përpara se të përpunoni vlerat e marra, ju këshilloj të kontrolloni ekzistencën e tyre përmes funksioneve i vendosur (emri_ndryshores) ose bosh (emri_ndryshues)- këto funksione u trajtuan në mësimin e mëparshëm 2: variablat në PHP. Për shembull:

duke kontrolluar ekzistencën me isset: nëse është vendosur ($ _GET ["login"]) ( operatorët për të trajtuar hyrjen ... } //ose kontrolloni ekzistencën duke përdorur bosh: nëse bosh ($ _GET ["email"]) ( operatorët për përpunimin e postës elektronike ... } ?>

Në formë, mund të specifikoni emrin e skedarit që do të përpunojë vlerat e kaluara. Kjo bëhet duke përdorur atributin e veprimit të formularit, të cilit mund t'i caktohet adresa e këtij skedari. Si parazgjedhje, ky skedar i caktohet skedarit aktual (d.m.th. i përpunuar në skedarin ku ndodhet formulari). Këtu është një shembull në të cilin të dhënat nga një formular dërgohen për përpunim në skedarin srcipt.php:

Identifikohu: Email:

Skedari script.php duhet të përmbajë një lloj mbajtësi informacioni, përndryshe informacioni do të kalojë në bosh.

Metoda GET ka shumë disavantazhe:

Përdoruesi sheh vlerat e parametrave të kaluar;
Përdoruesi mund të falsifikojë lehtësisht parametrat e transmetuar;
Transmetim i papërshtatshëm i informacionit binar (duhet të kodoni në format teksti);
Sasia e të dhënave të transferuara është e kufizuar - 8 Kbajt;

Për shkak të disavantazheve të mësipërme, metoda GET përdoret vetëm në rastet kur duhet të transferoni një sasi të vogël të dhënash dhe këto të dhëna nuk janë në asnjë mënyrë sekrete.

Metoda POST

Metoda POST ndryshon nga GET në atë që të dhënat transmetohen në formë të mbyllur. Ekziston një grup superglobal $ _POST nga i cili mund të lexoni të dhëna si kjo: $ _POST ["emri_ndryshore"]... Për shembull:

Identifikohu: "> E-mail: ">
Duke përdorur grupin superglobal $ _POST, printoni vlerat e pranuara:* / jehonë "
login = ". $ _POST [" login "]; jehonë"
email = ". $ _POST [" email "];?>

Rezultati i ekzekutimit të kodit të përshkruar më sipër është paraqitur në figurën më poshtë:

Siç mund ta shihni, URL-ja nuk ka postscript, por megjithatë të dhënat u morën dhe u shfaqën.

shënim:
1) Vëllimi i vlerave të transmetuara me metodën POST është i kufizuar si parazgjedhje dhe është i barabartë me 8 MB. Për të rritur këtë vlerë, duhet të ndryshoni direktivën post_max_size në php.ini.

2) Në versionet e mëparshme të PHP, në vend të emrave të shkurtër të grupeve superglobale $ _GET dhe $ _POST, u përdorën emra më të gjatë: $ HTTP_GET_VARS dhe $ HTTP_POST_VARS. Ato janë të çaktivizuara si parazgjedhje në php 5, por mund t'i aktivizoni në skedarin e konfigurimit php.ini duke përdorur parametrin register_long_arrays. Në php 6, këta emra të gjatë nuk do të jenë të disponueshëm.

3) Përpara se të përpunoni variablat nga $ _POST, ju këshilloj të kontrolloni variablat për praninë e tyre, ashtu siç u bë me metodën GET.

Krijimi i standardit të Internetit Web 2.0 i lejoi përdoruesit jo vetëm të merrte informacion, por edhe të ndërvepronte në mënyrë aktive me përdoruesit e tjerë dhe shërbimet e internetit. Për të organizuar këtë reagim, etiketat shtesë u futën në gjuhën HTML për të dërguar informacionin e kërkuar në server. Për shembull, ky mund të jetë një formular regjistrimi, ose një formular për të shtuar një koment, ose për të krijuar një llogari personale (faqe rrjeti social), etj. Në këtë kapitull, ne do të shqyrtojmë një grup etiketash që ju lejojnë të organizoni ndërveprimin e përdoruesit me sitin.

6.1. GET dhe POST kërkesat

Për të organizuar ndërveprimin e përdoruesit me internetin, zhvilluesi i faqes duhet të sigurojë transferimin e kërkesave nga përdoruesi i faqes në serverin ku ndodhet kjo faqe. Ekzistojnë dy lloje kërkesash: kërkesat GET dhe POST.

MARR-kërkesat

Në ditët e para të internetit, kishte vetëm kërkesa GET. Ato përfaqësojnë transferimin e të dhënave direkt në shiritin e adresave të shfletuesit, me sintaksën e mëposhtme:

http: // domain / faqe? [parametri1 = vlera1] [& parametri2 = vlera2] ...

Këtu, grupi i të dhënave të transferuara në server fillon me karakterin "?" dhe ndahet me karakterin "&". Vetë të dhënat janë çifte

parametër = vlerë

Për shembull, nëse duhet të kaloni emrin dhe mbiemrin e përdoruesit në faqen e regjistrimit (për shembull, register.php) të faqes mysite.com, atëherë do të duket kështu:

http://mysite.com/register.php?fname=Ivan&lname=Ivanov

Duhet të theksohet se shfletuesit e versioneve të vjetëruara mund të perceptojnë gabimisht alfabetin cirilik dhe transferimi i shkronjave ruse do të kryhet gabimisht. Është më mirë të transferoni vetëm informacionin e shërbimit në formën e numrave dhe fjalëve në latinisht në kërkesat GET.

Disavantazhi i kërkesave GET është sasia e kufizuar e të dhënave të transferuara. Nga ana e serverit, vargu i pyetjes është i kufizuar në një vlerë maksimale. Për shembull, nëse madhësia maksimale e kërkesës mund të jetë 1024 karaktere, atëherë gjithçka që tejkalon këtë vlerë do të fshihet dhe më pas disa nga informacionet e transmetuara nuk do të përpunohen nga faqja e specifikuar e faqes. Kufizimi i dytë i rëndësishëm është aftësia për të transmetuar grupe karakteresh të përcaktuara rreptësisht. Për shembull, personazhet? dhe & janë tashmë të rezervuara dhe nuk mund të kalohen si vlera parametrash. Sidoqoftë, ky rregull mund të anashkalohet duke kaluar në vargun e pyetjes jo vetë karakterin, por vlerën e kodit të tij. Për ta bërë këtë, përdorni karakterin '%' të ndjekur nga kodi i karakterit, si kjo:

http://mysite.com/register.php?fname=%CC%DF%AD%1F%DS&lname=%DD

Këtu, vlerat e kodit specifikohen në heksadecimal për të ruajtur gjatësinë e pyetjes.

Pavarësisht këtyre mangësive, do të ishte jashtëzakonisht e vështirë të krijoheshin faqe pa kërkesa GET. Për shembull, ato janë të domosdoshme në rastet e inicializimit fillestar të faqes së faqes për një përdorues specifik, kur kërkesa tregon jo vetëm sitin dhe faqen aktuale, por edhe ID-në e saj, siç bëhet në rrjetin social Vkontakte:

http://vk.com/profile.php?id=12345678

Gjithashtu, kërkesat GET përdoren shpesh për të kontrolluar korrektësinë e adresës së emailit kur regjistroni një përdorues. Në këtë rast, përdoruesi merr një email me një lidhje aktivizimi në adresën e specifikuar të emailit dhe kjo lidhje është një kërkesë GET.

POST-kërkesat

Për të zgjidhur të metat e treguara të kërkesave GET, u shtuan kërkesat POST, të cilat lejojnë transferimin e sasive të mëdha të të dhënave në formë binare, d.m.th. pa shtrembërime dhe ndryshime në të dhënat e transmetuara. Kërkesa të tilla janë të mira për ngarkimin e skedarëve dhe imazheve në server. Për shembull, kur një përdorues ngarkon një imazh në profilin e tij të rrjetit social, kërkesat POST përdoren për këtë. Më shumë detaje rreth organizimit të kërkesave POST do të diskutohen më poshtë.

Ju mund të keni vënë re se në shumicën e sajteve mund të shihni adresat e mëposhtme:

Http: //site/index.php? Blog = 2

Këtu, edhe pa e ditur php, mund të merrni me mend se i referohemi skedarit indeks.php Por pak njerëz e dinë se çfarë vjen pas pikëpyetjes. Është shumë e thjeshtë: blog = 2 kjo është deklarata e ndryshores globale "$ _GET [" blog "]" me vlerën "2". Kështu, unë i kaloj një variabël skriptit që është përgjegjës për shfaqjen e informacionit nga baza e të dhënave. Le të shkruajmë një skenar të vogël në të cilin do të shihni qartë gjithçka:

nëse (isset ($ _ GET ["blog"])) (
echo $ _GET ["blog"];
}
?>

Ne përdorim deklaratën e kushtit nëse () pasi kushti është rreshti i mëposhtëm:

Isset ($ _ GET ["blog"])

isset () ju lejon të zbuloni nëse variabli që është specifikuar në kllapa ekziston, domethënë gjendja që përshkrova në kod tingëllon kështu: Nëse variabli $ _GET ["blog"] ekziston, atëherë shfaqni përmbajtjen e këtë variabël në ekran. Ja çfarë ndodhi:

Mendoj se është e qartë Një variabël global është duke u krijuar $ _MERRNI me identifikuesin që kemi deklaruar në shiritin e adresave ( në këtë rast me identifikuesin "blog")

Tani dua të sqaroj një pikë. Supozoni se duhet të deklarojmë dy variabla, si ta bëjmë këtë? Variabla e parë deklarohet pas pikëpyetjes "?" Variabla e dytë deklarohet pas shenjës së tillë "&" ( Të them të drejtën, nuk e di se çfarë është kjo shenjë), këtu është një shembull i deklarimit të tre variablave:

Http: //site/index.php? A = 1 & b = 2 & c = 3

Këtu është kodi i daljes:

if (isset ($ _ GET ["a"]) AND isset ($ _ GET ["b"]) AND isset ($ _ GET ["c"])) (
echo $ _GET ["a"]."
";
echo $ _GET ["b"]."
";
jehonë $ _GET ["c"]."
";
}
?>

Gjendja shkon si kjo:

Nëse ka një variabël globale $ _GET ["a"] dhe një ndryshore globale $ _GET ["b"] dhe një variabël globale $ _GET ["c"] atëherë shfaqini ato, këtu është rezultati:

Format

Para se të arrijmë në postim pyetje, ju duhet të kuptoni se cilat janë format? Pse është e nevojshme? Sepse ndryshorja globale $ _POST [""] krijohet përmes formularëve. Çfarë është një formë? Këto janë fusha për futjen e një lloj informacioni nga përdoruesi. Fushat janë në një rresht, fusha të mëdha, ka edhe butona radio, kutitë e kontrollit. Le të zgjidhim gjithçka në rregull ...

Formulari është një etiketë:

Formulari ka atribute, unë do të listoj ato më të zakonshmet:

Le të krijojmë një formë:

Si skedar mbajtës, e vendosa skedarin test.php siç është në të që unë shkruaj shembuj për ju. Kam vendosur mënyrën e dërgimit të postimit pasi këto metoda përdoren në 99.9% të rasteve. Formës sonë i dhashë një emër - formë

Tani le të zhytemi në botën e elementeve të formës. Gjëja e parë që duhet të kuptoni është se pothuajse të gjithë elementët janë etiketa. i vetmi ndryshim është në atributin lloji në këto etiketa. Më lejoni të rendis elementët e formës së përdorur:

Unë jam i sigurt që keni parë fusha të tilla më shumë se një herë, kështu që këtu, siç thonë ata: "pa komente"

Tani le të përpilojmë një pyetësor të shkurtër trajnimi me të cilin do të punojmë në vijim. Detyra jonë është të hartojmë një pyetësor të vogël që do të na tregojë emrin e personit që plotësoi, gjininë, nga cili vend është, ngjyrën e tij të preferuar dhe një fushë teksti ku përdoruesi mund të shtojë diçka për veten e tij. Kjo është ajo që bëra:

Mbiemri juaj Emri Patronimik:

Cila është gjinia juaj:
M
F

Nga cili shtet jeni

Ngjyra(t) e preferuar:

E zezë:
E kuqe:
E bardhë:
Një tjetër:

Për veten time:

Vini re se pothuajse çdo etiketë ka një atribut vlerë, për çfarë është? Ai regjistron të dhënat që do të transferoni në një faqe tjetër. Shpresoj se është e qartë

Tani nëse e ekzekutojmë këtë kod në një shfletues, do të shohim sa vijon:

Kam përdorur atributin për formën veprim me kuptimin test.php kjo do të thotë, siç thashë, të dhënat nga formulari do të kalojnë në skedarin test.php.

Kërkesa POST

Tani le të shkruajmë kodin php që do të na lejojë të shohim informacionin që kemi futur. Ku ruhen të dhënat? Në rastin e kërkesës për të marrë, të dhënat tona u ruajtën në variablin global $ _GET [""]. Kur bëhet një kërkesë për postim, të dhënat do të jenë në variablin global $ _POST [""]. Në kllapa katrore, duhet të shkruani identifikuesin, si në rastin me variablin global get. Pyetja është, ku mund ta marr këtë identifikues? Kjo është arsyeja pse ne kemi nevojë për atributin e emrit në elementët e formës! Janë këta emra që shërbejnë si çelës për ne në postimin e grupit global. Epo, le të fillojmë të përshkruajmë skenarin:

nëse (isset ($ _ POST ["dorëzo"])) (
jehonë "Emri:". $ _ POST ["fio"]."
";
jehonë "Seksi:". $ _ POST ["seks"]."
";
echo "Vendi i vendbanimit:". $ _ POST ["qyteti"]."
";

Echo "Ngjyra (t) e preferuar:
";
echo $ _POST ["color_1"]."
";
echo $ _POST ["color_2"]."
";
echo $ _POST ["color_3"]."
";
echo $ _POST ["color_4"]."
";
echo "Rreth meje:". $ _ POST ["rreth"]."

";
}
?>

Kushti if që kemi shkruar thotë: Nëse ekziston një variabël global $ _POST ["submit"], atëherë ne i shfaqim të dhënat në ekran. Kjo variabël globale krijohet nëse klikojmë në butonin dërgo, prandaj në këtë shembull na duhet atributi emri në buton. Ju mund të pyesni veten pse atributi i emrit është opsional për butonin? Është shumë e thjeshtë. Zakonisht programuesi nuk gjurmon shtypjen e butonit, por gjurmon të dhënat e dërguara. Për funksionimin e saktë të, për shembull, formularët e kontaktit, është e nevojshme të gjurmoni jo shtypjen e një butoni, por saktësinë e informacionit të futur dhe të zbuloni nëse ky informacion është futur fare. Në shembullin tonë, ne nuk kontrolluam të dhënat e dërguara, por thjesht gjurmuam klikimin e butonit, për të thjeshtuar shembullin ... Ja çfarë morëm:

konkluzioni

Epo, sot kemi analizuar dy metoda të transferimit të të dhënave midis skripteve, si dhe galopët u njohën me format. Unë me të vërtetë shpresoj se ky informacion do të jetë i dobishëm për ju të paktën diku. Nëse keni ndonjë pyetje ose mendim, shkruani komente. Fat i mirë, kam gjithçka për sot!

PS: Dëshironi që lojërat kompjuterike të bëhen edhe më realiste? Directx 11 për Windows 7 mund të shkarkohet falas në Windows në! Shijoni grafika të shkëlqyera!

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

Në këtë artikull, unë dua t'ju tregoj se cilat janë metodat HTTP GET / POST / PUT / DELETE dhe të tjera, për çfarë janë shpikur dhe si t'i përdorin ato në përputhje me REST.

HTTP

Pra, cili është saktësisht një nga protokollet kryesore të internetit? Unë do t'i dërgoj pedantët në RFC2616, dhe do t'i tregoj pjesën tjetër si njeri :)

Ky protokoll përshkruan komunikimin ndërmjet dy kompjuterëve (klientit dhe serverit), bazuar në mesazhet e quajtura Kërkesë dhe 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 linja e fillimit.

Linjat fillestare për kërkesën dhe përgjigjen kanë një format të ndryshëm - 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ë vetëm metoda e kërkesës HTTP, URI është identifikuesi i burimit, VERSION është versioni i protokollit (versioni 1.1 është aktualisht i rëndësishëm).

Titujt janë një koleksion çiftesh emër-vlerë, të ndara me dy pika. Informacione të ndryshme të shërbimit transmetohen në titujt: kodimi i mesazhit, emri dhe versioni i shfletuesit, adresa nga erdhi klienti (Referruesi) dhe kështu me radhë.

Trupi i mesazhit është, në fakt, të dhënat e transmetuara. Në përgjigje, të dhënat e transmetuara, si rregull, janë 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, trupi i mesazhit nuk përfshihet fare në kërkesë.

Shembull i komunikimit HTTP

Le të shohim një shembull.

Hetim:
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 kërkesës, 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 Përmbajtja-Lloji: tekst / html; charset = utf-8 Përmbajtja-Gjatësia: 1234 Lidhja: mbyll ... VETË FAQJA HTML ...

Burimet dhe metodat

Le të kthehemi te vargu fillestar i pyetjes dhe të kujtojmë se ai 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ë një objekt abstrakt ("/ blogs / webdev /" - tregon blloku "Zhvillimi i uebit", dhe jo për një skedar specifik).

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

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

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

Kushtojini vëmendje faktit që specifikimi HTTP nuk e detyron serverin të kuptojë të gjitha metodat (të cilat në fakt janë shumë më tepër 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ë metodë të veçantë. Kjo do të thotë që serveri i përgjigjet një kërkese DELETE /index.php HTTP / 1.1 nuk është i detyruar të fshini faqen index.php në server, ashtu si në kërkesën GET /index.php HTTP / 1.1 nuk është i detyruar të të kthejë faqen index.php tek ju, ajo mund ta fshijë atë si :)

REST hyn në lojë

REST (Representational State Transfer) - ky term u krijua në 2000 nga Roy Fielding - një nga zhvilluesit e protokollit HTTP - si një emër për një grup 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 në rrjete të tjera me protokolle të tjera. REST përshkruan parimet e ndërveprimit klient-server, bazuar në konceptet e "burimit" dhe "foljes" (mund t'i kuptoni ato si subjekt dhe kallëzues). Në rastin e HTTP, burimi përcaktohet nga URI i tij, dhe folja është metoda HTTP.

REST propozon të braktisë përdorimin e të 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 nuk janë një mënyrë REST) dhe përdorimi 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 aksesoni atë me metodën HTTP DELETE (natyrisht, kjo nuk do të thotë që ju duhet të jeni në gjendje të fshini gjithçka dhe gjithçka, 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 kurrë 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 - fshin.

Probleme?

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

Kërkesat PUT / DELETE mund të dërgohen nëpërmjet XMLHttpRequest, duke kontaktuar serverin "manualisht" (të themi, nëpërmjet curl ose edhe nëpërmjet telnet), por nuk mund të bëni një formular HTML duke dërguar 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 funksionimin normal me metoda të tjera, duhet t'i imitoni ato artificialisht. Për shembull, në Rack (mekanizmi me të cilin 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 të quajtur "_method" në një formular dhe të specifikoni emrin e metodë si vlerë (për shembull, "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, jo një POST.

Ky postim ka për qëllim të shpjegojë parimet e transferimit 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 punës me turne për ata që nuk janë të interesuar për detajet ☺.

Shkoni në adresën e mëposhtme (kjo është për shpjegim vizual): http://calendarin.net/calendar.php?year=2016 Kushtojini vëmendje shiritit të adresave të shfletuesit: calendarin.net/calendar.php viti = 2016 Skedari kryesor emërtohet, i ndjekur nga një pikëpyetje (?) dhe një parametër "vit" me një vlerë "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, por disa, atëherë ato duhet të ndahen me një ampersand (&). Shembull: calendarin.net/calendar.php ? viti = 2016 & shfaqja = ditë pune dhe ditë pushimi

Skedari kryesor është ende i emërtuar, i ndjekur nga një pikëpyetje (?), Pastaj - parametri "vit" me vlerën "2016", pastaj - ampersand (&), pastaj - parametri "shfaq" me vlerën "punë -ditët-dhe-ditët -off".

Parametrat GET mund të ndryshohen drejtpërdrejt në shiritin e adresave të shfletuesit. Për shembull, duke ndryshuar vlerën "2016" në "2017" dhe duke shtypur tastin, do të shkoni në kalendarin për 2017.

Ky është transmetimi i të dhënave në mënyrë të fshehur (adresa e faqes nuk ndryshon); d.m.th., mund të shihni se çfarë është transmetuar vetëm me ndihmën e një programi (skripti). Për shembull, në mjetin e mëposhtëm për numërimin e karaktereve në një tekst, të dhënat burimore transmetohen duke përdorur metodën POST: http://usefulonlinetools.com/free/character-counter.php

Nëse keni ndonjë pyetje, komente dhe E-mail-in tim 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ë hyrë në server duke përdorur metodën GET, ishte e mjaftueshme që ne të shkruanim kërkesën në URL, atëherë në metodën POST gjithçka funksionon sipas një parimi tjetër.

Për të përmbushur këtë lloj kërkese, duhet të klikojmë në butonin me atributin tip = "submit", i cili ndodhet në faqen e internetit. Vini re se ky buton ndodhet në element me atributin e metodës të vendosur në postim.

Merrni parasysh këtë HTML:

Fut tekstin:

Nëse përdoruesi fut ndonjë tekst në fushën e tekstit dhe klikon në butonin "Dërgo", atëherë ndryshorja e tekstit me vlerën e përmbajtjes së futur nga përdoruesi do të dërgohet në server.

Kërkesat POST dhe GET në terma të thjeshtë

Kjo variabël do të dërgohet me metodën POST.

Nëse shkruani në këtë formë:

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, metoda POST fsheh të gjitha variablat që i kalohen 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 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
hyrje = Dima dhe 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, kështu që metoda POST konsiderohet më e sigurt.

Për më tepër, metoda POST mund të transferojë 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ë transferohet.

Së fundi, ndryshorja POST përdoret për të tërhequr të dhënat e transmetuara nga kjo metodë në server.

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 te serveri dhe serveri t'i dërgojë përgjigjet HTTP klientit. Këto kërkesa dhe përgjigje përpunohen sipas rregullave të caktuara. Ka diçka si sintaksa, si dhe në çfarë sekuence duhet të shkruhet. Duhet të ketë një strukturë të mirëpërcaktuar.

Le të hedhim një vështrim më të afërt në këtë strukturë, e cila përdoret për të ndërtuar kërkesa dhe përgjigje në protokollin HTTP.

Një kërkesë HTTP përbëhet nga tre pjesë kryesore, të cilat vijnë pikërisht në rendin e treguar më poshtë. Ekziston një vijë e zbrazët midis titujve dhe trupit të mesazhit (si ndarës), është një karakter i furnizimit të linjës.

Varg bosh (ndarës)

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 transmetimit, URL-në për të hyrë dhe versionin e protokollit HTTP.

Titujt- të përshkruajë trupin e mesazheve, të transmetojë parametra të ndryshëm dhe informacione e informacione të tjera.

trupi i mesazhit- këto janë vetë të dhënat, të cilat transmetohen në kërkesë. Trupi i mesazhit është opsional dhe mund të hiqet.

Kur marrim një kërkesë për përgjigje nga serveri, trupi i mesazhit është më së shpeshti 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 feedback-ut në server.

Në mënyrë më të detajuar, çdo element të kërkesës, do të shqyrtojmë në shënimet e mëposhtme.

Le të marrim një kërkesë reale të serverit si shembull. Çdo pjesë të kërkesës e kam theksuar me ngjyrën e vet: vija e kërkesës është e gjelbër, titujt janë portokalli, trupi i mesazhit është blu.

Kërkesë nga shfletuesi:

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; grup karakteresh = UTF-8

Transferimi-Enkodimi: i copëtuar

Lidhja: mbaj gjallë

Keep-Alive: skadimi = 5

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

Dokument pa titull

Këto janë mesazhet që shkëmbehen ndërmjet klientit dhe serverit përmes protokollit HTTP.

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

Hiqni atë që NUK funksionon, shtoni atë që funksionon dhe dyfishoni vlerën tuaj përfundimtare.

Një kurs për vendosjen e qëllimeve Yandex Metrica ..

Një kurs për vendosjen 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:

vargun e kërkesës (kërkohet)
Titulli (element opsional)
Varg bosh (kërkohet)
Trupi i mesazhit (opsionale)

Le të hedhim një vështrim në secilin prej këtyre elementeve veç e veç.

Vargu i pyetjes

Vargu i 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 shqyrtojmë këtë element në më shumë detaje.

Metoda e kërkesës

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

Ekzistojnë tetë metoda në HTTP:

KOKË
Përdoret për të marrë vijën e statusit dhe titullin nga serveri me URI. Nuk i ndryshon të dhënat.
MARR
Përdoret për të marrë të dhëna nga serveri në URI të specifikuar. Nuk i 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 sapo ngarkuara.
FSHIJE
Heq 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ë të pasme të vendndodhjes së URI të burimit të specifikuar.

Kërko URI

URI (Uniform Resource Identifier) është identifikuesi i burimit në të cilin është dërguar kërkesa. Formati më i zakonshëm URI tregohet më poshtë:

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

uri absolute përdoret kur një kërkesë HTTP i bëhet një përfaqësuesi. Proxy-it i kërkohet të kalojë kërkesën nga cache e disponueshme dhe kthen një përgjigje. Për shembull:

asbolutny_shtegu | një burim përdoret nga shumica e chatso-ve.

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

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

Kërkon fushat e kokës

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

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, ne do të shikojmë përgjigjet HTTP.

Një nga mënyrat se si mund të dërgoni një kërkesë HTTP në server është një kërkesë GET. Kjo metodë është më e zakonshme dhe më shpesh kërkesat për server bëhen 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ë transmetojë informacionin e mëposhtëm në server:

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: tekst / html, aplikacion / xhtml + xml, aplikacion / 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. linjë kërkesa

2.titujt (Titujt e mesazheve)

Ju lutemi vini re se kërkesa GET nuk ka një trup mesazhi. Por, kjo nuk do të thotë se me ndihmën e tij ne nuk mund të transferojmë 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ë kërkesë, duhet të vendosni një shenjë "?" në fund të URL-së. dhe pas tij, filloni t'i pyesni ata sipas rregullit të mëposhtëm:

parametri_emri1 = parametri_vlera1 & parametri_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 pyetje ekzekutohet, të dhënat shkojnë në të ashtuquajturën ndryshore të mjedisit QUERY_STRING, nga e cila mund të merren në server duke përdorur gjuhën e programimit të uebit nga ana e serverit.

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

jehonë "Emri juaj:". $ _MERRNI ["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.