MERRNI ose POST: çfarë të zgjidhni? Përdorimi i metodave GET dhe POST.

09.08.2019 Lajme

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

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

HTTP

Pra, cili është një nga protokollet kryesore të internetit? Unë do të dërgoj pedantë në RFC2616, dhe pjesën tjetër do t'i tregoj 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ë: linja e fillimit, titujt dhe trupi. Në këtë rast, kërkohet vetëm linja e fillimit.

Linjat e fillimit 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ë grup ç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ë të vërtetë të dhënat e transmetuara. Në përgjigje, të dhënat e transmetuara, si rregull, janë faqja html e kërkuar nga 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

Konsideroni 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ë vargu i pyetjes, pjesa tjetër janë kokë; mungon trupi i mesazhit

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 te vargu fillestar i pyetjes dhe të kujtojmë se ai përmban një parametër të tillë si një 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, çdo objekt abstrakt mund të jetë gjithashtu një burim ("/blogs/webdev/" - tregon për "zhvillimin e uebit", 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 mund të krijoni postime, të modifikoni një profil, të fshini mesazhe dhe shumë më tepër duke përdorur protokollin HTTP. Dhe është e vështirë të kombinohen këto veprime 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 burimeve
PUT - përditësimi i burimeve
FSHI - fshirja e një burimi

Kushtojini vëmendje faktit që specifikimi HTTP nuk e detyron serverin të kuptojë të gjitha metodat (të cilat në të vërtetë janë 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ë metodë të veçantë. Kjo do të thotë se serveri, në përgjigje të një kërkese 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ë ju kthen faqen index.php, ai mund ta fshijë atë, për shembull :)

REST hyn në lojë

REST (Representational State Transfer) - ky term u prezantua 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ë internet. 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 midis klientit dhe serverit, bazuar në konceptet e "burimit" dhe "foljes" (mund t'i kuptoni ato si një subjekt dhe një kallëzues). Në rastin e HTTP, burimi përcaktohet nga URI i tij, dhe folja është metoda HTTP.

REST propozon të ndalojë 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 - kjo nuk është një mënyrë REST) dhe të përdoren të ndryshme Metodat 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 aksesohet me metodën DELETE HTTP (natyrisht, kjo nuk do të thotë se ë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 DELETE HTTP).

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 shtimin e një përdoruesi 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 aplikimin e REST në praktikë. Ky problem quhet HTML.

Kërkesat PUT / DELETE mund të dërgohen përmes XMLHttpRequest, duke kontaktuar manualisht serverin (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.

Fakti është se specifikimi HTML nuk ju lejon të krijoni forma që dërgojnë të dhëna përveçse nëpërmjet GET ose POST. Prandaj, për funksionimin normal me metoda të tjera, është e nevojshme t'i imitoni ato artificialisht. Për shembull, në Rack (mekanizmi në bazë të të cilit Ruby ndërvepron me një server 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ë formular dhe të specifikoni emri i metodës 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.

Aktualisht, vetëm dy metoda HTTP përdoren më së shpeshti: GET dhe POST. Por doli që edhe midis këtyre dy "pishave" zhvilluesit e uebit arrijnë të humbasin. Ekziston një shpjegim për këtë: të dyja metodat mund të përdoren për të marrë të njëjtin rezultat. Por duhet mbajtur mend se përdorimi i nxituar i cilësdo prej metodave mund të çojë në pasoja katastrofike, duke përfshirë ngarkesa të mëdha 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 thelloheni në kuptimin e emrave të metodave, shumë do të bëhen 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 (c anglisht dërgo me postë) - përdoret për të dërguar të dhëna në server. Gjithçka duket të jetë shumë e thjeshtë dhe e qartë. Por kush dëshiron të zhvillojë faqe pak më të komplikuara se një faqe kartëvizitash me një formular reagimi, është më mirë ta njohë më mirë këtë çështje.

Kërkesa të sigurta dhe të pasigurta HTTP

Specifikimi HTTP 1.1 prezanton dy koncepte: një kërkesë të sigurt dhe një kërkesë të pasigurt, ose më konkretisht, një metodë.

Të sigurta janë metodat që mund të kërkojnë vetëm informacion. Ata nuk mund të ndryshojnë burimin e kërkuar, as nuk mund të prodhojnë 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 një imazhi. Metodat e sigurta janë KOKA dhe MERRNI.

Shënimi

Në realitet, zejtarët, natyrisht, mund të dëmtojnë edhe kërkesat e GET. Për shembull, unazat e pyetjeve.

Kërkesat e pasigurta, e keni marrë me mend, mund të çojnë në pasoja të këqija nëse ato përdoren në mënyrë të përsëritur. 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ë veti e metodave që do të kthejnë të njëjtin rezultat kur thirren në mënyrë të përsëritur, përveç nëse 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 ueb, imazh, video, etj. Metodat GET, PUT, DELETE e kanë këtë veti.

Dhe tani më shumë rreth vetë metodave GET dhe POST: le të bëjmë 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ërpunohen në anën e serverit më shpejt dhe me më pak konsum të burimeve të serverit për shkak të një trupi të kërkesës bosh;
variablat transferohen 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 mbrohen);
të aftë për të kaluar një sasi të vogël të dhënash në server: ekziston një kufizim në gjatësinë e URL-së, e cila varet nga shfletuesi, për shembull, IE6 = 2Kb. Zhvilluesit e Yahoo rekomandojnë që të fokusohen në këtë numër;
mund të transmetojë vetëm karaktere ASCII;
një kërkesë e tillë mund të kopjohet, ruhet (për shembull, në faqerojtësit);
kërkesa mund të ruhet në memorie (kjo mund të kontrollohet);
kërkesat e kushtëzuara dhe të pjesshme janë të disponueshme për të reduktuar më tej ngarkesën në kanal dhe server;
nuk e prish lidhjen HTTP (kur modaliteti keepAlive është i aktivizuar në server).

POST

projektuar për të dërguar të dhëna në server;
transferimi i të dhënave ndodh në trupin e kërkesës;
Përpunimi nga ana e serverit është më i ngadalshëm dhe "më i rëndë" se GET, sepse përveç titujve, ju duhet të analizoni trupin e kërkesës;
të aftë për të transferuar sasi të mëdha të dhënash;
në gjendje të transferojë skedarë;
një faqe e krijuar nga metoda POST nuk mund të shënohet;
prish lidhjen HTTP;
për të transferuar 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ë trup kërkese.

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, në shumicën e rasteve është një opsion më i mirë, veçanërisht kur ndërtoni AJAX të shpejtë, por mos harroni për të metat e tij. Për veten time, bëra një shënim të thjeshtë algoritmi për zgjedhjen e metodës.

1. Protokolli HTTP. Prezantimi

Dua të sqaroj vetëm një gjë të vogël. Fjala e tmerrshme protokoll nuk është gjë tjetër veçse një marrëveshje e shumë njerëzve, vetëm në një moment të bukur njerëzit vendosën: "Ta bëjmë kështu, dhe pastaj gjithçka do të jetë në rregull". Nuk ka asgjë për t'u frikësuar, gjithçka është thjesht e egër dhe ne tani do ta hapim këtë zemërim. Pra, çfarë është protokolli HTTP dhe me çfarë hahet?

1.1 Klienti dhe serveri

Nuk ka mrekulli në botë dhe aq më tepër në botën e programimit dhe internetit! Përqafojeni këtë si një të vërtetë të palëkundur. Dhe, nëse programi nuk funksionon ose nuk funksionon siç dëshironi, atëherë, ka shumë të ngjarë, ai ose nuk është shkruar saktë ose përmban gabime. Pra, si i kërkon shfletuesi serverit t'i dërgojë diçka? Po, shumë e lehtë! Thjesht duhet të relaksoheni pak dhe të filloni të shijoni procesin :-)

1.2. Shkrimi i kërkesës sonë të parë HTTP

Nëse mendoni se gjithçka është shumë e ndërlikuar, atëherë gaboheni. Një person është rregulluar në atë mënyrë që ai thjesht nuk është në gjendje të krijojë diçka komplekse, përndryshe ai vetë do të ngatërrohet në këtë :-) Pra, ekziston një shfletues dhe ka një server në internet. Iniciatori i shkëmbimit të të dhënave është gjithmonë shfletuesi. Serveri i uebit kurrë nuk do t'i dërgojë asgjë askujt në mënyrë që të dërgojë diçka në shfletuesin - është e nevojshme që shfletuesi ta kërkojë atë. Kërkesa më e thjeshtë HTTP mund të duket kështu:

MERRNI http://www.php.net/ HTTP/1.0rnrn

* GET (Përkthyer nga anglishtja do të thotë "merr") - lloji i kërkesës, lloji i kërkesës mund të jetë i ndryshëm, për shembull POST, HEAD, PUT, DELETE (do t'i shqyrtojmë disa prej tyre më poshtë).
* http://www.php.net/ - URI (adresa) nga e cila duam të marrim të paktën disa informacione (natyrisht, shpresojmë të mësojmë një faqe HTML).
* HTTP/1.0 - lloji dhe versioni i protokollit që do të përdorim në procesin e komunikimit me serverin.
* rn - fundi i rreshtit, i cili duhet të përsëritet dy herë, pse, do të bëhet e qartë pak më vonë.

Ju mund ta bëni këtë kërkesë shumë lehtë. Drejtoni programin telnet.exe, futni www.php.net si host, specifikoni portin 80 dhe thjesht shkruani këtë kërkesë duke shtypur Enter dy herë më rnrn. Si përgjigje, ju do të merrni kodin HTML të faqes kryesore të faqes www.php.net.

1.3 Struktura e kërkesës

Le të shohim se nga përbëhet një kërkesë HTTP. Gjithçka është mjaft e thjeshtë. Le të fillojmë me faktin se një kërkesë HTTP është një tekst plotësisht kuptimplotë. Nga çfarë përbëhet në rastin e përgjithshëm? Ne do të shqyrtojmë protokollin HTTP 1.0. kështu që :

Kërkesë - Linja [ Përgjithshme - Header | Kërkesë - Kreu | Entity - Header ] rn [ Entity - Body ]

* Linja e kërkesës - linja e kërkesës
*

Formati : "Kërkesa e metodës-URI HTTP-Versionrn"
* Metoda - metoda me të cilën do të përpunohet burimi Request-URI mund të jetë GET, POST, PUT, DELETE ose HEAD.
* Kërkesë-URI - lidhje relative ose absolute në një faqe me një grup parametrash, për shembull, /index.html ose http://www.myhost.ru/index.html ose /index.html?a=1&b=qq . Në rastin e fundit, një kërkesë do t'i dërgohet serverit me një grup variablash a dhe b me vlerat përkatëse, dhe karakteri ampersand "&" shërben si ndarës midis parametrave.
* Versioni HTTP - Versioni i protokollit HTTP, në rastin tonë "HTTP/1.0".

Ne jemi jashtëzakonisht të interesuar për metodat e përpunimit GET dhe POST. Me metodën GET, thjesht mund t'i kaloni parametrat skriptit, dhe me metodën POST, mund të imitoni formularët e dorëzimit.

Për një metodë GET, Request-URI mund të duket diçka si kjo: "/index.html?param1=1¶m2=2".

* General-Header - pjesa kryesore e kokës.
Formati:
Mund të ketë vetëm dy parametra: Data ose Pragma. Data - Data GMT në formatin "Dita e javës, Dita Muaji Viti HH:MM:SS GMT", për shembull, "E martë, 15 nëntor 1994 08:12:31 GMT" - data kur u krijua kërkesa. Pragma mund të ketë një vlerë pa memorie, e cila çaktivizon cachimin e faqeve.

* Request-Header - pjesë e kokës që përshkruan kërkesën.

Request-Header mund të ketë parametrat e mëposhtëm : Lejo, Autorizim, Nga, Nëse-Modified-Since, Referer, User-Agent.
Ne nuk do të mbulojmë parametrin Autorizimi në këtë kapitull, pasi përdoret për të hyrë në burime private, gjë që shpesh nuk nevojitet. Mund të mësoni se si të krijoni një kokë për akses të autorizuar vetë në www.w3c.org.

* Lejo - vendos metodat e lejuara të përpunimit.
Formati: "Lejo: GET | HEADn".
Parametri injorohet kur specifikohet metoda e përpunimit POST në linjën e kërkesës. Përcakton metodat e vlefshme të përpunimit të kërkesës. Përfaqësuesit e serverit nuk e modifikojnë parametrin Lejo dhe ai arrin në server i pandryshuar.

* Nga - adresa e e-mail e dërguesit të kërkesës.
Formati: "Nga:adderssrn".
Për shembull, "Nga: [email i mbrojtur]".

* Nëse-Modified-Since - Tregon që kërkesa nuk është modifikuar që nga një kohë e tillë.
Formati: "If-Modified-Since: datern"
Përdoret vetëm për metodën e mbajtësit GET. Data është e specifikuar në GMT në të njëjtin format si për parametrin Date në General-Header.

* Referruesi - një lidhje absolute në faqen nga e cila është nisur kërkesa, d.m.th. një lidhje në faqen nga e cila përdoruesi shkoi në faqen tonë.
Formati: "Referruesi: urln".
Shembull: "Referuesi: www.host.ru/index.htmln".
* Përdoruesi-Agjent - lloji i shfletuesit.
Për shembull: "Agjenti i përdoruesit: Mozilla/4.0n"

* Entity-Header - pjesë e titullit që përshkruan të dhënat e Entitetit-Trupit.
Në këtë pjesë të kërkesës vendosen parametra që përshkruajnë trupin e faqes. "Entity-Header" mund të përmbajë parametrat e mëposhtëm: Allow, Content-Encoding, Content-Length, Content-Type, Expires, Last-Modified, Extension-header.

* Lejo - parametër i ngjashëm me Allow from General-Header.

* Content-Encoding - Lloji i kodimit të të dhënave Entity-Body.
Formati: "Enkodimi i përmbajtjes: x-gzip | x-compress | lloj tjetër".
Shembull: "Përmbajtje-Enkodimi: x-gzipn". Simboli "|" do të thotë fjala “ose”, pra ky apo ai apo ai, etj.
Një lloj tjetër mund të tregojë se si kodohen të dhënat, për shembull, për metodën POST: "Content-Encoding: application/x-www-form-urlencodedn".

* Gjatësia e përmbajtjes - numri i bajteve të dërguara te Enti-Trupi. Vlera Content-Length ka një kuptim krejtësisht të ndryshëm për të dhënat e dërguara në formatin MIME, ku vepron si një parametër për të përshkruar pjesën "e jashtme/entitet-trup" të të dhënave. Numrat e plotë të vlefshëm janë zero ose më shumë.
Shembull: "Përmbajtja-Gjatësia: 26457n".

* Content-Type - lloji i të dhënave të transmetuara.
Për shembull: "Lloji i përmbajtjes: tekst/htmln".

* Skadon - Koha kur faqja duhet të hiqet nga cache e shfletuesit.
Formati: "Skadon: datë". Formati i datës është i ngjashëm me formatin e datës për parametrin Date nga General-Header.

* Last-Modified - koha e modifikimit të fundit të të dhënave të dërguara.
Formati: "Ndryshimi i fundit: data". Formati i datës është i ngjashëm me formatin e datës për parametrin Date nga General-Header.

* Extension-header - pjesë e kokës, e cila mund të synohet, për shembull, të përpunohet nga shfletuesi, ose një program tjetër që pranon dokumentin. Në këtë pjesë, ju mund të përshkruani parametrat tuaj në formatin "ParameterName: parametervaluen". Këto parametra do të injorohen nëse programi i klientit nuk di se si t'i përpunojë ato.
Për shembull: "Cookie: r=1rn" - vendos cookie-t e njohura për faqen.

Dhe tani, pas fjalëve kaq të tmerrshme, le të përpiqemi të qetësohemi pak dhe të kuptojmë se çfarë kemi nevojë? Natyrisht do ta kuptojmë me shembuj.

Le të imagjinojmë se duhet të marrim një faqe nga faqja duke kaluar Cookies (Cookies), përndryshe thjesht do të dërgohemi si mysafirë të paftuar dhe për më tepër, dihet që kjo faqe lejohet vetëm pasi të keni vizituar faqen kryesore të faqe.

2 Metoda GET

Le të shkruajmë kërkesën tonë.

MERR http :
pritës: www. faqe. vrapoj

Cookie: të ardhura = 1rn
rn

Kjo kërkesë na tregon se ne duam të marrim përmbajtjen e faqes në http://www.site.ru/news.html duke përdorur metodën GET. Fusha Host tregon që kjo faqe ndodhet në serverin www.site.ru, fusha Referer tregon se kemi ardhur nga faqja kryesore e faqes për lajme dhe fusha "Cookie" tregon që një cookie e tillë dhe ajo i është caktuar ne. Pse janë kaq të rëndësishme fushat Host, Referer dhe Cookie? Sepse programuesit normalë, kur krijojnë faqe dinamike, kontrollojnë këto fusha që shfaqen në skriptet (përfshirë PHP) në formën e variablave. Për çfarë është? Në mënyrë që, për shembull, të parandalohet grabitja e faqes, d.m.th. ata nuk vendosën një program për shkarkimin automatik në të, ose në mënyrë që një person që vinte në sit të arrinte gjithmonë në të vetëm nga faqja kryesore, etj.

Tani le të imagjinojmë se duhet të plotësojmë fushat e formularit në faqe dhe të dërgojmë një kërkesë nga formulari, le të ketë dy fusha: hyrje dhe fjalëkalim (hyrje dhe fjalëkalim), dhe, natyrisht, ne e dimë hyrjen dhe fjalëkalimin .

MERR http : //www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0rn
pritës: www. faqe. vrapoj
Referuesi: http: //www.site.ru/index.htmlrn
Cookie: të ardhura = 1rn
rn

Hyrja jonë është "Petya Vasechkin" Pse duhet të shkruajmë Petya%20Vasechkin? Kjo është për shkak se karakteret speciale mund të njihen nga serveri si shenja të një parametri të ri ose përfundimi i një kërkese, etj. Prandaj, ekziston një algoritëm për kodimin e emrave të parametrave dhe vlerave të tyre, në mënyrë që të shmangen situatat oshbokovnyh në kërkesë. Një përshkrim i plotë i këtij algoritmi mund të gjendet këtu, dhe PHP ka funksione rawurlencode dhe rawurldcode për kodim dhe dekodim, përkatësisht. Dua të vërej se PHP e bën vetë dekodimin nëse parametrat e koduar kalojnë në kërkesë. Mbi këtë do të mbyll kapitullin e parë të njohjes me protokollin HTTP. Në kapitullin tjetër, do të shikojmë ndërtimin e kërkesave POST (përkthyer nga anglishtja - "dërgo"), të cilat do të jenë shumë më interesante, sepse. Ky lloj kërkese përdoret kur dërgohen të dhëna nga formularët HTML.

3. Metoda POST.

Në rastin e një kërkese HTTP POST, ekzistojnë dy opsione për kalimin e fushave nga formularët HTML, përkatësisht duke përdorur algoritmin e aplikacionit/x-www-form-urlencoded dhe me shumë pjesë/formë-të dhëna. Dallimet midis këtyre algoritmeve janë shumë domethënëse. Fakti është se algoritmi i llojit të parë u krijua shumë kohë më parë, kur gjuha HTML nuk parashikonte ende mundësinë e transferimit të skedarëve përmes formave HTML. Pra, le t'i shohim këto algoritme me shembuj.

3.1 Lloji i përmbajtjes: aplikacioni/x-www-form-urlencoded.

Ne shkruajmë një kërkesë të ngjashme me kërkesën tonë GET për të transferuar hyrjen dhe fjalëkalimin, e cila u diskutua në kapitullin e mëparshëm:

POSTO http: //www.site.ru/news.html HTTP/1.0rn
pritës: www. faqe. vrapoj
Referuesi: http: //www.site.ru/index.htmlrn
Cookie: të ardhura = 1rn
Përmbajtja - Lloji: aplikacioni / x - www - forma - urlencodedrn
Përmbajtja - Gjatësia : 35rn
rn

Këtu shohim një shembull të përdorimit të fushave të titullit Content-Type dhe Content-Length. Content-Length tregon se sa bajt do të zërë zona e të dhënave, e cila ndahet nga kreu me një rresht tjetër të ri rn. Por parametrat që ishin vendosur më parë në Kërkesë-URI për një kërkesë GET tani janë në Entity-Body. Mund të shihet se ato janë formuar saktësisht në të njëjtën mënyrë, thjesht duhet t'i shkruani ato pas titullit. Dua të shënoj një pikë më të rëndësishme, asgjë nuk pengon, njëkohësisht me grupin e parametrave në Entity-Body, të vendosësh parametra me emra të tjerë në Kërkesë-URI, për shembull:

POSTO http: //www.site.ru/news.html?type=përdoruesi HTTP/1.0rn
.....
rn
hyrje = Petya % 20Vasechkin & fjalëkalimi = qq

3.2 Lloji i përmbajtjes: të dhëna me shumë pjesë/formë

Sapo bota e internetit kuptoi se do të ishte mirë të dërgoheshin skedarë përmes formularëve, konsorciumi W3C mori përsipër rishikimin e formatit të kërkesës POST. Deri në atë kohë, formati MIME (Zgjatjet e postës në internet me shumë qëllime - shtesat e protokollit me shumë qëllime për gjenerimin e mesazheve të postës) ishte përdorur tashmë gjerësisht, prandaj, për të mos rishpikur timonin, vendosëm të përdorim një pjesë të këtij formati mesazhi për të krijuar POST kërkesat në protokollin HTTP.

Cilat janë ndryshimet kryesore midis këtij formati dhe llojit të aplikacionit/x-www-form-urlencoded?

Dallimi kryesor është se Entiteti-Trupi tani mund të ndahet në seksione që ndahen me kufij (kufi). Ajo që është më interesante është se çdo seksion mund të ketë titullin e vet për të përshkruar të dhënat që ruhen në të, d.m.th. në një kërkesë, mund të transferoni të dhëna të llojeve të ndryshme (si në një letër Mail, mund të transferoni skedarë së bashku me tekstin).

Pra, le të fillojmë. Konsideroni përsëri të njëjtin shembull me transferimin e hyrjes dhe fjalëkalimit, por tani në një format të ri.

POSTO http: //www.site.ru/news.html HTTP/1.0rn
pritës: www. faqe. vrapoj
Referuesi: http: //www.site.ru/index.htmlrn
Cookie: të ardhura = 1rn

Përmbajtja - Gjatësia : 209rn
rn
-- 1BEF0A57BE110FD467Arn
Përmbajtja-Dispozita: formë-të dhëna; emri = "hyrja" rn
rn
Petya Vasechkinrn
-- 1BEF0A57BE110FD467Arn
Përmbajtja-Dispozita: formë-të dhëna; emri = "fjalëkalimi" rn
rn
qqrn
-- 1BEF0A57BE110FD467A -- rn

Tani le të kuptojmë se çfarë është shkruar. :-) I shkrova me guxim disa nga karakteret rn me qëllim që të mos përzihen me të dhënat. Duke parë nga afër, mund të shihni fushën e kufirit pas Llojit të Përmbajtjes. Kjo fushë specifikon ndarësin e seksionit - kufirin. Si kufi, mund të përdoret një varg i përbërë nga shkronja dhe numra latine, si dhe disa karaktere të tjera (për fat të keq, nuk mbaj mend se cilat prej tyre). Në trupin e kërkesës, "--" shtohet në fillim të kufirit dhe kërkesa përfundon me një kufi, të cilit i shtohen edhe karakteret "--" në fund. Kërkesa jonë ka dy seksione, e para përshkruan fushën e hyrjes dhe e dyta përshkruan fushën e fjalëkalimit. Përmbajtja-Disposition (lloji i të dhënave në seksion) thotë se këto do të jenë të dhëna nga formulari, dhe fusha e emrit vendoset në emrin e fushës. Kjo përfundon kokën e seksionit dhe pasohet nga zona e të dhënave të seksionit, e cila përmban vlerën e fushës (nuk kërkohet kodim i vlerës!).

Dua të tërheq vëmendjen tuaj për faktin se në titujt e seksionit nuk keni nevojë të përdorni Content-Length, por në kokën e kërkesës është e nevojshme dhe vlera e tij është madhësia e të gjithë Entitetit-Trupit pas rn-së së dytë pas Përmbajtja-Gjatësia: 209rn. ato. Entity-Body ndahet nga kreu me një linjë të re shtesë (e cila mund të shihet gjithashtu në seksione).

Tani le të shkruajmë një kërkesë për të transferuar skedarin.

POSTO http: //www.site.ru/postnews.html HTTP/1.0rn
pritës: www. faqe. vrapoj
Referues: http://www.site.ru/news.htmlrn
Cookie: të ardhura = 1rn
Lloji i përmbajtjes: shumëpjesësh/formë-të dhëna; kufiri = 1BEF0A57BE110FD467Arn
Përmbajtja - Gjatësia: 491 rn
rn
-- 1BEF0A57BE110FD467Arn
Përmbajtja-Dispozita: formë-të dhëna; emri = "header_news" rn
rn
Shembull i lajmeve
-- 1BEF0A57BE110FD467Arn
Përmbajtja-Dispozita: formë-të dhëna; emri = "file_lajmi" ; filename="news.txt" rn
Përmbajtja - Lloji : aplikacion / oktet - streamrn
Përmbajtja - Transferimi - Kodimi : binaryrn
rn
Dhe ja ku është lajmi, që gjendet në dosjen e lajmeve. txtrn
-- 1BEF0A57BE110FD467A -- rn

Në këtë shembull, seksioni i parë dërgon titullin e lajmit dhe seksioni i dytë dërgon skedarin news.txt. Ai i vëmendshëm do të shohë emrin e skedarit dhe fushat e llojit të përmbajtjes në seksionin e dytë. Fusha e emrit të skedarit specifikon emrin e skedarit që po ngarkohet dhe fusha Content-Type specifikon llojin e skedarit. Application/oktet-stream tregon se ky është një rrjedhë standarde e të dhënave dhe Content-Transfer-Encoding: binar tregon se këto janë të dhëna binare, të pa koduara në asgjë.

Një pikë shumë e rëndësishme. Shumica e skripteve CGI janë shkruar nga njerëz të zgjuar, kështu që u pëlqen të kontrollojnë llojin e skedarit në hyrje, i cili është në llojin e përmbajtjes. Per cfare? Më shpesh, shkarkimi i skedarëve në sajte përdoret për të marrë fotografi nga një vizitor. Pra, vetë shfletuesi përpiqet të përcaktojë se çfarë lloj skedari dëshiron të dërgojë vizitori dhe fut në kërkesë llojin e duhur të përmbajtjes. Skripti e kontrollon atë pas marrjes, dhe, për shembull, nëse nuk është një gif ose jpeg, ai e injoron këtë skedar. Prandaj, kur gjeneroni "me dorë" një kërkesë, kujdesuni për vlerën Content-Type në mënyrë që të jetë më afër formatit të skedarit që transferohet.

Imazhi/gif për gif
imazh/jpeg për jpeg
imazh/png për png
imazh/tiff për tiff (i cili përdoret rrallë, është një format shumë i gjerë)

Në shembullin tonë, formohet një kërkesë në të cilën transmetohet një skedar teksti. Në mënyrë të ngjashme, formohet një kërkesë për të transferuar një skedar binar.

4. Passhkrim.

Unë mendoj se nuk ia vlen të flasim për dërgimin e kërkesave në server në detaje. Kjo është thjesht një çështje e teknologjisë PHP :-). Mjafton të lexoni me kujdes seksionin mbi funksionet e prizës, ose mbi funksionet e modulit CURL në dokumentacionin zyrtar PHP.

Nga sa më sipër, shpresoj se tani është e qartë pse pyetja është: "Si mund të formoj një kërkesë POST duke përdorur funksionin e kokës?" - e pakuptimtë. Funksioni header(string) shton një hyrje vetëm në kokën e kërkesës, jo në trupin e kërkesës.

Mbrapa

Po, të gjithë kanë mësuar diçka në një moment. E vetmja gjë që i dallon njerëzit në këtë drejtim është se për disa, mësimet jepen lehtësisht, ndërsa të tjerë nuk mund ta kuptojnë thelbin e çështjes për shumë muaj. Sot do të flasim për kërkesat POST dhe GET në HTML\PHP.

Vetë kërkesat POST dhe GET (në tekstin e mëtejmë të referuara si kërkesa) kanë qenë prej kohësh të rrënjosura në të gjitha burimet e Internetit. Nëse papritmas një ditë shfaqet një alternativë ndaj këtyre teknologjive, atëherë me siguri nuk do të jetë së shpejti dhe ndoshta nuk do të jetë e nevojshme. Sepse kërkesat tona përmbushin plotësisht detyrën e shkëmbimit të të dhënave ndërmjet faqeve të internetit.

Le të shohim së pari një kërkesë GET. Le të krijojmë një skedar index.php me një kod standard html dhe të vendosim një formular në të, le të jetë një formular porosie produkti.

Le t'i hedhim një sy etiketës këtu. formë. Ka dy parametra veprim Dhe metodë. E para është përgjegjëse për adresën e faqes në të cilën do të transferojmë të dhënat tona, e dyta është për metodën me të cilën do të transferohen këto të dhëna. Brenda kësaj etikete, ne përshkruajmë grupin e të dhënave tona që duam të transferojmë. Emrat duhet t'u caktohen të dhënave (parametri emri). Kërkohet gjithashtu lloji i hyrjes paraqesin, i cili është butoni që dërgon të dhënat kur klikohet.

Le ta ruajmë skedarin tonë dhe ta hapim atë në një shfletues.
Rruga e faqes sonë në shfletues është ".../index.php". Në vetë faqen, ne shohim dy fusha hyrëse dhe një buton. Le të plotësojmë diçka në fushat tona dhe të klikojmë në butonin "Porosit". Faqja jonë është përditësuar. Le të shohim adresën e saj: ".../index.php?orderName=Test&count=12". (Kam shtypur në fushën e parë fjalën 'Test' në të dytën '12'). Siç mund ta shohim, adresa e faqes ka ndryshuar pak. Fakti është se transmetimi i parametrave GET nga një kërkesë kryhet duke i caktuar ato në vargun e adresës së faqes. Parametrat ndahen nga adresa kryesore me karakterin '?' dhe parametrat e ndryshëm me karakterin '&'. Struktura e parametrave është si më poshtë: parametri_emri=vlera. Emri i parametrit do të përputhet me vlerën e atributit të emrit në fushën e hyrjes.
Le të modifikojmë pak kodin e faqes:

> >

Tani klikoni përsëri në butonin "Porosit". Siç mund ta shohim, faqja është përditësuar, por fushat tona kanë mbetur të mbushura. Kjo për faktin se kemi dhënë një vlerë të paracaktuar për fushat tona. Për më tepër, këto vlera janë parametri i marrë GET. Siç mund ta shohim në kodin PHP, parametrat GET janë një grup me një indeks vargu të barabartë me emrin e parametrit. Nëse tani luajmë me adresën e faqes dhe ndryshojmë vlerat e parametrave në të dhe shtypim butonin "Enter", atëherë do të vërejmë përsëri një foto me përditësimin e faqes dhe plotësimin e formularit tonë.

Natyrisht, dërgimi i të dhënave sekrete ose shërbimi në një kërkesë GET është i gabuar (dhe jo i sigurt). Është më mirë ta përdorni për të transferuar, për shembull, ID-në e lajmit që duhet të merret nga baza e të dhënave ose emrin e faqes që duhet të shfaqet.

Kërkesa POST është një çështje tjetër. Punon në mënyrë të ngjashme, por nuk ruan parametrat në shiritin e adresave. Le të ndryshojmë formën tonë:

$_POST ["emri i porosisë"]?> > $_POST["count"]?> >

Sidoqoftë, siç mund ta shihni, nuk ka ndryshuar shumë! Le të hapim faqen tonë, të plotësojmë diçka në fushat dhe të shtypim butonin "Porosit". Gjithçka funksionoi në të njëjtën mënyrë, megjithatë (megjithatë), siç e shohim në vargun e pyetjeve, adresa "…/index.php" shfaqet pa asnjë lloj parametri. Kështu, ne disi "i fshehëm" të dhënat tona nga sytë kureshtarë. Sigurisht, koncepti ishte i fshehur, mjaft i kushtëzuar, pasi këto të dhëna ende mund të përgjohen, por kjo është një histori tjetër. Le të shtojmë parametrat ".../index.php?orderName=Trololo&count=100" në adresën tonë dhe shtypim "Enter". Siç mund ta shohim, faqja është ngarkuar, por edhe pavarësisht kalimit të parametrave, fushat rezultuan bosh. Kjo sugjeron që pavarësisht ngjashmërisë së madhe, këto lloj kërkesash nuk kryqëzohen në asnjë mënyrë me njëra-tjetrën dhe nëse është e nevojshme, ia vlen të shkruhet një trajtues për çdo lloj kërkese veç e veç.

Mendoj se mjafton. Bazat e pyetjes, mendoj, përshkruhen me kokë.

Dhe pak më shumë… Mos harroni të kontrolloni parametrat e kaluar. Nëse e dini me siguri që parametri duhet të jetë një numër, atëherë shkurtoni të gjitha përpjekjet për të kaluar një vlerë jo numerike, etj ...

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

http://website/index.php?blog=2

Këtu, edhe pa e ditur php, mund të merrni me mend se ne po i qasemi skedarit indeks.php Por çfarë vjen pas pikëpyetjes, pak njerëz e dinë. Gjithçka ë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:

if(isset($_GET["blog"])) (
echo $_GET["blog"];
}
?>

Ne përdorim operatorin e kushtit if() si kusht, ekziston kjo linjë:

Isset ($_GET["blog"])

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

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

Tani dua të sqaroj një pikë. Supozoni se duhet të deklarojmë dy variabla, si ta bëjmë atë? Variabla e parë deklarohet pas pikëpyetjes "?" Ndryshorja e dytë deklarohet pas një shenje të tillë "&" ( Për të qenë i sinqertë, nuk e di se çfarë është ajo shenjë.), këtu është një shembull i deklarimit të tre variablave:

http://website/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"])) (
jehonë $_GET["a"]."
";
jehonë $_GET["b"]."
";
jehonë $_GET["c"]."
";
}
?>

Gjendja tingëllon 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 në ekran, këtu është rezultati:

Format

Përpara se të kalojmë 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ë teme informacioni nga përdoruesi. Fushat janë në një rresht, fusha të mëdha, ka edhe butona radio, kutitë e kontrollit. Le t'i marrim të gjitha me radhë ...

Formulari është një etiketë:

elementet e formës

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

Le të krijojmë një formë:

elementet e formës

Si një skedar mbajtës, e vendosa skedarin test.php sepse është në të që unë shkruaj shembuj për ju. E vendosa mënyrën e dërgimit për të postuar sepse 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. ndryshimi është vetëm në atribut lloji këto etiketa. Më lejoni të rendis elementët e formës së përdorur:

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

Tani le të bëjmë një pyetësor të vogël trajnimi, me të cilin do të punojmë më tej. Detyra jonë është të përpilojmë një pyetësor të vogël që do të na tregojë emrin e personit që e plotësoi, gjininë, nga cili vend është, ngjyrën e 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:

Gjinia juaj:
M
F

Nga cili shtet jeni

Ngjyra(t) e preferuara:

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

Për veten time:

Vini re se pothuajse çdo etiketë ka një atribut vlerë per cfare eshte? Ai përmban 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 në formular veprim me kuptim test.php kjo do të thotë, siç thashë, që të dhënat nga formulari do të transferohen në skedarin test.php.

Kërkesa POST

Tani le të shkruajmë një kod php që do të na lejojë të shohim informacionin që kemi futur. Ku ruhen të dhënat? Në rastin e një kërkese për të marrë, të dhënat tona ishin në variablin global $_GET[""]. Me një kërkesë postimi, të dhënat do të ruhen në variablin global $_POST[""]. Në kllapa katrore, duhet të shkruani, si në rastin e ndryshores globale get, një identifikues. 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ësi ynë në grupin post global. Epo, le të fillojmë të përshkruajmë skenarin:

if(isset($_POST["dorëzo"])) (
echo "Emri: ".$_POST["fio"]."
";
echo "Gjinia: ".$_POST["sex"]."
";
echo "Vendi i banimit: ".$_POST["qytet"]."
";

Echo "Ngjyra(t) e preferuar:
";
jehonë $_POST["color_1"]."
";
jehonë $_POST["color_2"]."
";
jehonë $_POST["color_3"]."
";
jehonë $_POST["color_4"]."
";
echo "Rreth meje: ".$_POST["about"]."

";
}
?>

Kushti if që kemi shkruar thotë: Nëse variabli global $_POST["submit"] ekziston, 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 të butonit është opsional? Gjithçka është mjaft e thjeshtë. Zakonisht, programuesi nuk monitoron shtypjen e butonit, por monitoron të dhënat e dërguara. Për funksionimin e saktë, për shembull, një formular kontakti, është e nevojshme të gjurmoni jo shtypjen e butonit, por saktësinë e futjes së informacionit 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, për sot kemi analizuar dy metoda të transferimit të të dhënave midis skripteve, dhe gjithashtu u njohëm me format në një galop. Unë me të vërtetë shpresoj se ky informacion është i dobishëm për ju. Nëse keni ndonjë pyetje ose mendim, shkruani komente. Fat të mirë, kjo është e gjitha për sot!

P.S.: Dëshironi që lojërat kompjuterike të bëhen edhe më realiste? Directx 11 për Windows 7 mund ta shkarkoni falas në Windows in! Shijoni grafika të mrekullueshme!