POST și GET solicitări în cuvinte simple. Care este diferența dintre POST și GET

Crearea standardului de Internet Web 2.0 a permis utilizatorului nu numai să primească informații, ci și să interacționeze activ cu alți utilizatori și cu serviciile de Internet. Pentru a organiza un astfel de feedback, au fost introduse tag-uri suplimentare în limbajul HTML, permițând transmiterea informațiilor solicitate către server. De exemplu, acesta ar putea fi un formular de înregistrare, sau un formular pentru adăugarea unui comentariu sau configurarea unui cont personal (pagina de rețea socială), etc. În acest capitol, vom analiza un set de etichete care vă permit să organizați interacțiunea utilizatorului cu site-ul.

6.1. solicitări GET și POST

Pentru a organiza interacțiunea utilizatorului cu Internetul, dezvoltatorul site-ului trebuie să prevadă transmiterea solicitărilor de la utilizatorul site-ului către serverul pe care se află site-ul. Există două tipuri de solicitări: solicitări GET și POST.

solicitări GET

În stadiul incipient al dezvoltării Internetului, existau doar cereri GET. Acestea reprezintă transferul de date direct către bara de adrese a browserului, având următoarea sintaxă:

http://domain/page?[parameter1=value1][¶meter2=value2]...

Aici, setul de date transferate către server începe cu caracterul „?” și este separat de caracterul „&”. Datele în sine sunt o pereche

parametru=valoare

De exemplu, dacă trebuie să treceți numele și prenumele utilizatorului pe pagina de înregistrare (de exemplu, register.php) a site-ului mysite.com, ar arăta astfel:

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

Vă rugăm să rețineți că este posibil ca browserele versiunilor învechite să nu perceapă corect alfabetul chirilic și transmiterea literelor rusești va fi efectuată incorect. Este mai bine să transmiteți exclusiv informații de serviciu în cererile GET sub formă de numere și cuvinte în latină.

Dezavantajul solicitărilor GET este numărul limitat de date transferate. Pe partea de server, șirul de interogare este limitat la o valoare maximă. De exemplu, dacă dimensiunea maximă a cererii poate fi de 1024 de caractere, atunci tot ceea ce depășește această valoare va fi șters și apoi o parte din informațiile transmise nu vor fi procesate de pagina specificată a site-ului. A doua limitare semnificativă este capacitatea de a transmite seturi de caractere strict definite. De exemplu, simboluri? și & sunt deja rezervate și nu pot fi transmise ca valori ale parametrilor. Cu toate acestea, această regulă poate fi ocolită dacă șirul de interogare conține nu caracterul în sine, ci valoarea sa de cod. Pentru a face acest lucru, utilizați caracterul „%” urmat de codul caracterului, de exemplu astfel:

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

Aici valorile codului sunt date în hexazecimal pentru a salva lungimea interogării.

În ciuda acestor dezavantaje, crearea de site-uri fără solicitări GET ar fi extrem de dificilă. De exemplu, acestea sunt indispensabile în cazurile de inițializare inițială a unei pagini de site pentru un anumit utilizator, atunci când cererea specifică nu numai site-ul și pagina curentă, ci și id-ul acesteia, așa cum se face în rețeaua socială VKontakte:

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

Solicitările GET sunt adesea folosite pentru a verifica corectitudinea adresei de e-mail la înregistrarea unui utilizator. În acest caz, utilizatorul primește un e-mail cu un link de activare la adresa de e-mail specificată, iar acest link este o solicitare GET.

solicitări POST

Pentru a rezolva aceste neajunsuri ale cererilor GET, au fost adăugate cereri POST, permițând transferul unor cantități mari de date în formă binară, de exemplu. fără distorsiuni sau modificări ale datelor transmise. Astfel de solicitări sunt potrivite pentru încărcarea fișierelor și imaginilor pe server. De exemplu, atunci când un utilizator încarcă o imagine în profilul său de rețea socială, solicitările POST sunt folosite pentru aceasta. Mai multe detalii despre organizarea cererilor POST vor fi discutate mai jos.

Astăzi am vrut să mă adâncesc puțin în lucrurile primitive și să descriu ceea ce se găsește pe World Wide Web în cantități mari și fără prea multe dificultăți. Vom vorbi practic despre sfântul sfintelor protocolului HTTP: cererile POST și GET.

Mulți se vor întreba de ce? Voi răspunde pe scurt și clar: nu toată lumea știe ce este și de ce este nevoie, iar cei care vor să învețe despre ea (în timp ce înțeleg puțin în domeniul IT) de multe ori nu pot înțelege ce este scris în multe, multe articole consacrate acestui lucru subiect. Voi încerca să explic cu degetele mele ce sunt cererile POST și GET și pentru ce sunt folosite.
Deci, să începem călătoria noastră într-un basm...
Dacă citiți acest mesaj, atunci cel puțin știți cum arată Internetul și ce este un site de Internet. După ce am omis toate complexitățile activității World Wide Web, vom opera cu concepte precum utilizator și site. Orice s-ar spune, aceste două entități trebuie cumva să interacționeze între ele. De exemplu, oamenii comunică între ei prin gesturi, emoții și vorbire, animalele scot niște sunete, dar ce se întâmplă atunci când o persoană și o resursă de internet „comună”? Aici avem un caz de schimb de informații, care poate fi transferat într-o conversație umană „Întrebare-Răspuns”. Mai mult, atât utilizatorul, cât și site-ul pot pune întrebări și răspunsuri. Când vorbim despre un site web, întrebările și răspunsurile sale, de regulă, sunt întotdeauna exprimate sub forma unei pagini de internet cu un text sau altul. Când vine vorba de utilizator, atunci totul se întâmplă datorită solicitărilor GET și POST (desigur nu numai, dar vorbim despre ele).

Astfel, am aflat că obiectele noastre tematice sunt necesare pentru a „comunica” cu site-urile. Mai mult, atât solicitările GET, cât și POST pot fi folosite pentru a „pune întrebări” site-ului și pentru a „răspunde” la ele. In ce fel sunt ei diferiti? Totul este destul de simplu. Totuși, pentru a explica diferențele, va trebui să luăm în considerare un exemplu, pentru care vom lua site-ul unui plan de magazin online.
Probabil ați observat adesea când căutați ceva în magazinele online că atunci când căutați folosind filtre, adresa site-ului se transformă din frumosul „http://magaazin.ru” în înfricoșătorul „http://magaazin.ru/?category = pantofi și mărime = 38". Deci, tot ceea ce vine după simbolul '?' este cererea dvs. GET către site și, pentru a fi complet precis, în acest caz întrebați site-ul ce are în categoria „Pantofi” de la mărimile „38” (acest exemplu este luat din capul meu, în realitate totul poate să nu pară atât de evident). Ca urmare, avem că putem pune întrebări noi înșine, indicându-le în bara de adrese a site-ului. Evident, această metodă are mai multe dezavantaje. În primul rând, oricine se află lângă utilizator la computer poate spiona cu ușurință toate datele, așa că utilizarea acestui tip de solicitare pentru transferul parolelor este extrem de nedorită. În al doilea rând, există o limită a lungimii șirului care poate fi transferat din câmpul de adresă a site-ului, ceea ce înseamnă că nu va fi posibil să transferați multe date. Cu toate acestea, avantajul incontestabil al utilizării cererilor GET este ușurința sa de utilizare și capacitatea de a interoga rapid site-ul, ceea ce este util în special în timpul dezvoltării, dar asta este o altă poveste...
Acum să vorbim despre solicitările POST. Este posibil ca cititorii inteligenți să fi realizat că principala diferență între această solicitare și omologul său este secretul datelor transmise. Dacă luăm în considerare un magazin online, un exemplu izbitor în care se folosește o solicitare POST este înregistrarea pe site. Site-ul vă solicită datele, completați aceste date și când faceți clic pe butonul „Înregistrare” trimiteți răspunsul dumneavoastră. Mai mult, aceste date nu vor fi afișate în niciun fel extern. De asemenea, este de remarcat faptul că o cantitate destul de mare de informații poate fi solicitată - iar cererea POST nu are restricții. Ei bine, dacă atingeți minusul, atunci o astfel de solicitare nu poate fi generată rapid. Nu poți face asta fără abilități speciale. Deși în realitate totul nu este atât de dificil, dar din nou, aceasta este o altă poveste.
Să rezumam. Solicitările POST și GET sunt necesare pentru „comunicarea” între utilizator și site. Ele sunt în esență aproape opuse unul față de celălalt. Utilizarea anumitor tipuri de interogări depinde de situația specifică și utilizarea unui singur tip de interogare este extrem de incomod.

De foarte multă vreme îmi doream să scriu un articol în care să vorbesc despre diferența dintre metoda POST și metoda GET, dar cumva au apărut și alte subiecte și am trecut la ele. Și acum, în sfârșit, a sosit momentul să acoperim acest subiect, deoarece de multe ori oamenii pur și simplu nu știu care este diferența dintre POST și GET.

Pentru a afișa mai clar diferența dintre POST și GET, ofer un tabel care arată caracteristicile prin care diferă.

Pe baza acestei caracteristici, putem concluziona când să folosim POST și când să folosim GET. De exemplu, dacă utilizatorul dorește să marcheze pagina generată. Apoi generarea trebuie să aibă loc printr-o solicitare GET, altfel adăugarea paginii la marcaje nu va funcționa. Un alt exemplu: atunci când transmiteți un login și o parolă, nu puteți utiliza metoda GET, deoarece se bazează pe transmiterea datelor prin bara de adrese. În caz contrar, după ce faceți clic pe butonul „Trimite”, ceva de genul acesta va apărea în bara de adrese: „http://mysite.ru/login.php?log=User&pass=123456”, - și oricine poate vedea parola, care, desigur, nu ar trebui permis. Prin urmare, aici trebuie să folosim metoda POST.

De asemenea, nu uitați că dimensiunea datelor care pot fi transferate folosind metoda POST este cu un ordin de mărime mai mare decât atunci când sunt transferate folosind metoda GET. În general, analizați acest tabel și trageți o concluzie: ce metodă de transfer de date ar trebui utilizată într-un anumit caz. Voi adăuga pe cont propriu că în 80% din cazuri ar trebui să utilizați POST, dar nu uitați că acest lucru este departe de 100%.

Dacă aveți întrebări sau doriți să comentați acest articol, vă puteți lăsa comentariul în partea de jos a paginii.

Comentarii (15):

dsmts 05/12/2013 14:00:18

Bună ziua Am nevoie de așa ceva când redirecționez: header("Locație: test.php"); Valoarea $_POST a fost transmisă acestei pagini. Pagina din care trebuie transmisă această valoare nu are nicio formă. Acestea. pur și simplu prelucrează datele și generează o cerere specifică. Momentan am transferul efectuat folosind cookie-uri. Dar nu sunt sigur dacă este sigur. Sau gresesc? Datele care sunt transmise nu trebuie să fie vizibile pentru utilizatori.

Răspuns

Alex_ 23.11.2013 23:56:10

O zi buna :), Mihail! Încerc să scriu un plugin în PHP și am descoperit în mod natural că îmi lipsesc cunoștințele. De aici și întrebarea: dacă un anumit site (sistem de plată), după acțiunile mele din partea mea, îmi trimite date către site pe o anumită pagină folosind metoda POST, ar trebui să le văd dacă scriu print_r($_POST) în script ? ? Doar în cazul meu, de exemplu print_r($_SERVER); puteți vedea ce date sunt în matricea $_SERVER, dar $_POST este gol, adică fie datele nu ajung, fie am o viziune profană despre cum sunt lucrurile cu adevărat.

Răspuns

23.11.2013 23:59:31

Bună ziua, Alexander De obicei, sistemele de plată transmit datele în ordine inversă în formă criptată și folosind protocoale securizate. Deci totul depinde de sistemul de plată. Scrieți un modul de plată pentru un anumit sistem? Vă rugăm să vă clarificați întrebările, altfel nu vă voi putea ajuta.

Răspuns

Alex_ 24.11.2013 02:00:41

Salut Alexandru, multumesc pentru raspuns. Scriu un plugin pentru cms Wordpress, lucrând cu sistemul de plată interkassa.com. Dacă achiziția are succes, aceasta va redirecționa către pagina de plată cu succes http://my_site/success. Conform documentației, datele care îmi sunt vizibile vin pe această pagină. Adică, în setări am selectat metoda de transfer GET și vine un URL lung, acest link și în el parametrii http://my_site/success/?&ik_payment_id=1&ik_paysystem_alias=yandexdengir, totul este așa cum ar trebui să fie. Am încercat să selectez metoda de transmitere POST, apoi în scriptul pe care l-am scris, de exemplu, if (isset($_POST["ik_trans_id"])) echo $_POST["ik_trans_id"]. Și a funcționat. Apoi am început să lucrez cu STATUS url pentru că atunci sosește ik_sign_hash, care este generat de intercash folosind o cheie secretă (care este cunoscută de mine și de intercash) și de data aceasta dacă (isset($_POST["ik_sign_hash"]) nu funcționează pentru ca nu este acolo Pe site-ul meu exista un plugin (nu face totul asa cum ne-am dori) scris in OOP (sunt inca departe de nivelul celui care a scris asta, poate de aceea nu este evident. pentru mine ce se folosește acolo). Acest plugin procesează totul și calculează hash-ul de pe partea sa, deoarece am schimbat-o în mod deliberat pe cheia secretă (în setările pluginului) și a fost trimis un e-mail cu o notificare despre datele transferate incorect (). hashe-urile nu s-au potrivit) și o solicitare de a contacta administratorul site-ului.

Răspuns

24.11.2013 02:09:28

Ei bine, nu ți-am văzut pluginul, așa că nu voi spune nimic anume. Cât despre implementarea simplă... nu am studiat API-ul interkassa. Puteți vedea o soluție simplă aici: http://goo.gl/rFnpNc În esență, este aceeași în toate sistemele. De obicei lucrez cu o casă de marcat robotizată sau cu onpei, așa că scuzați-mă. În general, structura este ceva de genul acesta Trebuie să scrieți o implementare în conformitate cu documentația API http://www.interkassa.com/faq.php vezi aici secțiunea Interkassa prin ochii unui programator și administrator + Acolo. la ultima întrebare există documentație tehnică pentru descărcare și mici lucruri despre API în general

Răspuns

Alex_ 24.11.2013 02:16:40

Mulțumesc, Alexandru. Am vazut, am citit toate astea, incerc de cateva zile si caut pe google si cred ca poate nu inteleg ceva :). http://goo.gl/rFnpNc - și acesta este un plugin de Andrey Morkovin, nu scris în întregime (probabil pentru a nu dezvălui toate secretele, scenariul este acum plătit). Pe baza acestuia au fost create mai multe lecții video despre cum să scrieți pluginuri pe WP. Acest plugin http://www.icprojects.net/paid-downloads-plugin.html este disponibil în versiuni plătite și gratuite. În versiunea gratuită, este disponibilă doar plata PAYPAL. dar totul este acolo și dacă modificați câteva valori, modul Interkassa în versiunea beta devine disponibil.

Răspuns

24.11.2013 02:23:00

Da, sunt conștient de acest lucru, a existat doar un plugin, fie că a fost complet sau nu, poate că există o versiune care costă 40 USD. întins în jur. În orice caz, nu voi recomanda nimic anume. Citiți documentația API-ului Interkassa Iar algoritmii sunt aceiași peste tot Scrieți un handler care trimite datele în formă criptată și care le primește și le decriptează. Puteți să vă uitați la soluția lui Levchuk în pagina sa de wp ;) Dacă am timp, voi privi acest subiect mai detaliat

Ultima actualizare: 1/11/2015

Spre deosebire de cererile GET, datele cererilor POST sunt transmise nu în linia de solicitare, ci în corpul acesteia. Un exemplu comun de astfel de solicitări este trimiterea datelor de formular către server.

Metoda post este folosită pentru a trimite cereri POST. Declarația și utilizarea sa sunt în general similare cu metoda get. Acceptă următorii parametri:

url: un parametru obligatoriu care conține adresa resursei pe care o va accesa cererea

date: un parametru opțional care conține un obiect sau șir de caractere javascript simplu care va fi trimis la server împreună cu cererea

success(data, textStatus, jqXHR) : parametru opțional - o funcție de apel invers care va fi executată atunci când cererea are succes. Poate lua trei parametri: date - date primite de la server, textStatus - starea cererii și jqXHR - un obiect jQuery special care reprezintă o versiune extinsă a obiectului XMLHttpRequest.

dataType: parametru opțional care conține tipul de date ca șir, cum ar fi „xml” sau „json”

La ieșire, metoda post returnează un obiect jqXHR.

Exemplu de utilizare:

$.post("ajax.php", ("login":"1111", "parola": "2222"), function(data) ( $("#news").html(data); ));

În acest caz, transmitem parola și autentificarea ca date. Pe server putem primi date și trimite un răspuns utilizatorului:

Întrucât cererea de postare este folosită cel mai des la trimiterea datelor din formular, folosim formularul din partea clientului:

$("#loginForm").submit(function(event) ( // Preveniți trimiterea obișnuită a formularelor event.preventDefault(); $.post("ajax.php", ("login":$("#login")). val(), "parolă" : $("#parolă").val()), function(date) ( $("#rezultat").html(date); ));

Deci, partea de server pe care o va accesa formularul - fișierul ajax.php - rămâne aceeași. Doar în acest caz, acum pentru parametrul de date din metoda post luăm date din câmpurile din acest formular.

Vă rugăm să rețineți că blocăm trimiterea normală a formularelor (event.preventDefault();), altfel am avea o redirecționare.

Serializarea unui formular

Deoarece formularele nu sunt adesea limitate la două câmpuri, este mai ușor să utilizați serializarea formularelor. Serializarea se realizează folosind metoda serialize și ca rezultat creează un obiect javascript, unde proprietățile corespund câmpurilor formularului. Și valorile stocate de aceste proprietăți sunt aceleași cu cele ale câmpurilor de formular corespunzătoare.

Deci, să aplicăm serializarea formularului:

$("#loginForm").submit(function(event) ( // Preveniți trimiterea obișnuită a formularelor event.preventDefault(); $.post("ajax.php", $("#loginForm").serialize(), funcție (date) ( $("#rezultat").html(date); ));

Spre deosebire de exemplul anterior, avem două diferențe aici. În primul rând, observați că câmpurile de intrare au un atribut de nume. La specificarea parametrului de date, serializam datele formularului prin metoda serialize: $("#loginForm").serialize() . În această metodă, parametrii sunt transferați corpului cererii. Mai mult decât atât, numele parametrilor sunt valorile atributelor de nume ale câmpurilor de intrare. Și valorile parametrilor sunt valorile corespunzătoare introduse în câmpurile de text.

Și astfel folosind php putem extrage aceste valori: $login=$_POST["login"] .

Ceea ce au în comun este că funcționează la fel. Din punct de vedere tehnic, nu există nicio diferență între ele. Dar există diferențe ideologice.

Voi vorbi despre ele în contextul PHP. Vă rugăm să rețineți că protocolul HTTP este indirect legat de PHP deoarece a fost creat pentru schimbul de pagini html și PHP pur și simplu extinde capacitățile ambelor.

Solicitarea GET este folosită pentru a primi date și POST este folosit pentru a trimite. (Amintiți-vă că din punct de vedere tehnic funcționează la fel).

Prin urmare, în contextul PHP, pe baza acestei ideologii, am făcut următoarele:
1. De fiecare dată când porniți PHP, matricele superglobale ($_GET, $_POST) sunt create implicit.
2. Dacă există un semn de întrebare (?) în șirul de interogare. Totul după care este considerat parametrii de solicitare GET sunt prezentați în formatul „cheie” = „valoare” și se folosește ca separator semnul ampersand (&).
Exemplu:
GET /index.php?name=Andrey&surname=Galkin
Acesta este un șir de interogare, există 2 parametri. acești parametri vor intra în matricea $_GET.
3. $_POST este completat într-un mod diferit. conținutul acestei matrice este completat din „antetele cererii”. Adică dintr-un loc clar ascuns vederii. Browserul se ocupă de toate treburile creării unor astfel de anteturi. Deși uneori ceva este editat în titluri manual.

Cel mai adesea, o cerere de postare este utilizată în formulare (pentru a trimite date).

De exemplu, avem un formular de autentificare cu 2 câmpuri: autentificare și parolă.

Să ne imaginăm că folosim metoda GET. Apoi, la trimiterea formularului, vom merge la următoarea adresă /login.php?login=Andrey&password=123 Veți fi de acord că transmiterea unor astfel de informații în acest mod nu este deloc sigură. Oricine vă poate deschide browserul și începând să introducă adresa site-ului, vă poate vedea parolele și login-urile din istoric.

Dar dacă am specifica metoda POST, am primi următoarea solicitare:
POST /login.php (login=Andrey&password=123) ceea ce este între paranteze ar fi ascuns și nu ar fi salvat în niciun fel în browser.

Pentru a rezuma:
GET este de a obține o anumită pagină într-o anumită formă (sortare, pagină curentă de blog, bară de căutare etc.).
POST - pentru trimiterea de date care nu afectează afișarea paginii, în sensul că aceste date afectează doar rezultatul scriptului (autentificări, parole, numere de card de credit, mesaje etc.).

Și o altă veste bună este că pot fi combinate, de exemplu
POST /index.php?page=login (login=Andrey&password=123) Cred că am explicat deja suficient ce va veni din asta și ce parametri vor intra în ce matrice.