HTTP määrittelee erilaisia tapoja olla vuorovaikutuksessa palvelimen kanssa, ja on olemassa neljä perusmenetelmää: GET, POST, PUT ja DELETE. URL-osoitteen koko nimi on resurssikuvaaja, voimme ajatella sitä näin: URL-osoite, jota käytetään kuvaamaan resurssia verkossa, ja GET, POST, PUT, DELETE HTTP:ssä vastaa neljää toimintoa: tarkistaa, muuttaa, lisätä ja poistaa tämä resurssi. Tässä vaiheessa sinulla pitäisi olla yleinen ymmärrys: GET:ää käytetään yleensä resurssitiedon hankkimiseen/kyselyyn, kun taas POST:ia käytetään yleensä resurssitiedon päivittämiseen.
1. HTTP-määrittelyn mukaan GET:tä käytetään tiedonhakuun ja sen tulisi olla turvallinen ja idempotentti.
(1). Niin sanottu turvallisuus tarkoittaa, että operaatiota käytetään tiedon hankkimiseen sen muokkaamisen sijaan. Toisin sanoen, GET-pyynnöillä ei yleensä pitäisi olla sivuvaikutuksia. Toisin sanoen se saa vain resurssitietoja, kuten tietokantakysely, eikä muokkaa, lisää dataa tai vaikuta resurssin tilaan.
* Huomautus: Turvallisuuden merkitys tässä viittaa vain muokkaamattomaan tietoon.
(2). idempotentti tarkoittaa, että useiden pyyntöjen lähettäminen samaan URL-osoitteeseen palauttaa saman tuloksen.
Käytännön soveltamisessa edellä mainitut kaksi säädöstä eivät kuitenkaan ole yhtä tiukkoja. Esimerkkejä muiden artikkeleiden lainaamisesta: Esimerkiksi uutissivuston etusivua päivitetään jatkuvasti. Vaikka toinen pyyntö palauttaa eri erän uutisia, operaatio katsotaan silti turvalliseksi ja idempotentiksi, koska se palauttaa aina ajankohtaiset uutiset. Periaatteessa, jos tavoitteena on, että kun käyttäjä avaa linkin, hän voi olla varma, ettei resurssia ole muutettu hänen näkökulmastaan.
2. HTTP-määrittelyn mukaan POST edustaa pyyntöä, joka voi muokata palvelimen resurssia. Jatkan yllä olevan esimerkin lainaamista: Still news Otetaan esimerkiksi verkkosivusto, lukijoiden tulisi julkaista omat kommenttinsa uutisista, koska sivuston resurssit muuttuvat kommentin lähettämisen jälkeen tai resursseja on muokattu.
Yllä oleva käsittelee karkeasti joitakin GET- ja POST-periaatteita HTTP-määritteyksissä. Monet eivät kuitenkaan noudata HTTP-määrittelyä tehdessään sitä, mikä voi johtaa moniin syihin, kuten:
1. Monet ihmiset käyttävät GET:tä resurssien päivittämiseen, koska heidän täytyy mennä FORMiin käyttääkseen POSTia, mikä voi olla hieman hankalaa.
2. Resurssien lisääminen, poistaminen, muokkaaminen ja tarkistaminen voidaan itse asiassa suorittaa GET/POST-toiminnolla ilman PUT- ja DELETE-toimintoja.
3. Toinen on se, että varhaiset Web MVC -kehyksen suunnittelijat eivät tietoisesti käsitelleet tai suunnitelleet URL-osoitteita abstrakteina resursseina, joten vakava ongelma on, että perinteinen Web MVC -kehys tukee käytännössä vain kahta HTTP-metodia, GET ja POST, mutta ei PUT- ja DELETE-metodeja.
* Lyhyt selitys MVC:stä: MVC oli alun perin olemassa työpöytäohjelmassa, M viittaa tietomalliin, V viittaa käyttöliittymään ja C ohjain. MVC:n tarkoituksena on erottaa M:n ja V:n toteutuskoodi siten, että sama ohjelma voi käyttää eri esityksiä.
Edellä mainitut kolme kohtaa kuvaavat tyypillisesti vanhaa tyyliä (ilman tiukkaa HTTP-määrittelyn noudattamista), arkkitehtuurin kehityksen myötä on olemassa REST (Representational State Transfer), uusi tyyli, joka tukee HTTP-määrittelyä.
Kun olemme keskustelleet pääongelmasta, tarkastellaan eroa GET:n ja POST:n välillä pintailmiön perusteella:
1. GET-pyynnön data liitetään URL-osoitteeseen (eli data sijoitetaan HTTP-protokollan otsikkoon), ja ? Jaa URL-osoite ja lähetä tiedot, ja parametrit yhdistetään seuraavasti: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Jos data on englanninkielisiä kirjaimia/numeroita, lähetä se sellaisenaan, jos se on välilykkö, muunna se +:ksi, jos kyseessä on kiina/muut merkit, ja salaa merkkijono suoraan BASE64:llä saadaksesi esimerkiksi: %E4%BD%A0%E5%A5%BD, missä XX %XX:ssa on ASCII, joka esitetään symbolilla kuusikodesimaalina.
POST sijoittaa lähetetyn datan HTTP-paketin runkoon.
2. "GET-menetelmän enimmäismäärä voi olla vain 1024 tavua, teoriassa POSTille ei ole rajoitusta, ja suuri määrä dataa voidaan siirtää, jopa 80KB IIS4:ssä ja 100KB IIS5:ssä"??!
Yllä oleva lause on ohjattu muista artikkeleista, itse asiassa on väärin ja epätarkkaa sanoa näin:
(1). Ensinnäkin, "GET-menetelmällä lähetetty data voi olla enintään 1024 tavua", koska GET lähettää dataa URL-osoitteen kautta, joten GET:n lähettämän datan määrä liittyy suoraan URL-osoitteen pituuteen. Itse asiassa URL-osoitteille ei ole yläparametrirajoitusta, eikä HTTP-protokollan määrittely rajoita URL-osoitteiden pituutta. Tämä rajoitus on rajoitus, jonka asettaa tietty selain ja palvelin. IE:n URL-pituuden raja on 2083 tavua (2K+35). Muille selaimille, kuten Netscapelle, FireFoxille jne., ei ole teoreettista pituusrajoitusta, ja sen rajoitus riippuu käyttöjärjestelmän tuesta.
Huomaa, että tämä rajoittaa koko URL-osoitteen pituutta, ei pelkästään parametrin arvon datan pituutta. [Katso viite 5]
(2). Teoreettisesti POSTilla ei ole kokorajaa, eikä HTTP-protokollan määrittelyllä ole kokorajaa, ja on virheellistä sanoa, että "POST-datalle on kokoraja 80K/100K", eikä POST-datalle ole rajoitusta, ja rajoittava rooli on palvelimen käsittelijän laskentateho.
ASP-ohjelmissa Request-objektilla on 100K datan pituusrajoitus kunkin lomakkeen kentän käsittelyssä. Mutta Request.BinaryReadissa tällaista rajoitusta ei ole.
Tästä eteenpäin Microsoft on lisännyt rajoituksia IIS 6.0:ssa turvallisuussyistä. Meidän on myös kiinnitettävä huomiota:
1). IIS 6.0 oletuksena on enintään 200 KB ASP POST -dataa, ja raja on 100 KB per lomakekenttä.
2). IIS 6.0 -lataustiedostojen oletuskoko on 4MB.
3). IIS 6.0 oletuksena on enimmäispyyntöotsikko 16KB.
Nämä rajoitukset eivät olleet saatavilla ennen IIS 6.0:aa. [Katso viite 5]
Joten yllä olevat 80K ja 100K saattavat olla oletusarvot (huom: en ole vielä vahvistanut IIS4:n ja IIS5:n parametreja), mutta voit ehdottomasti asettaa ne itse. Koska näiden parametrien oletusarvot vaihtelevat kussakin IIS-versiossa, lisätietoja löytyy asiaankuuluvasta IIS-konfiguraatiodokumentista.
3. ASP:ssä palvelin käyttää Request.QueryStringiä saadakseen GET-pyyntöparametrin ja Request.Formia saadakseen POST-pyyntöparametrin. JSP:ssä käytä request.getParameter(\"XXXX\") saadaksesi sen, vaikka jsp:ssä on myös request.getQueryString()-metodi, mutta sen käyttö on hankalampi, esimerkiksi: lähetä test.jsp?name=hyddd&password=hyddd ja käytä request.getQueryString() saadaksesi :name= hyddd&password=hyddd。 PHP:ssä voit käyttää $_GET ja $_POST saadaksesi dataa GET- ja POST-pyynnöistä, kun taas $_REQUEST saa dataa sekä GET- että POST-pyynnöistä. On syytä huomata, että pyyntöjen käytössä JSP:ssä ja $_REQUEST PHP:ssa on piileviä vaaroja, jotka tiivistetään seuraavalla artikkelilla.
4.POST on turvallisempi kuin GET. Huomautus: Tässä mainittu turvallisuus ei ole sama käsite kuin yllä mainittu "turvallisuus". Esimerkiksi, jos lähetät tietoja GET:n kautta, käyttäjätunnuksesi ja salasanasi näkyvät selväkielisinä URL-osoitteessa, koska (1) kirjautumissivu voi olla selaimen välimuistissa, (2) muut näkevät selaimen historian, jolloin muut voivat saada tilisi ja salasanasi väärennöshyökkäys.
Yhteenvetona: Get on pyyntö pyytää dataa palvelimelta, kun taas Post on pyyntö lähettää dataa palvelimelle, FORM-muodossa metodi oletuksena on "GET", eli GET ja POST ovat vain eri lähetysmekanismeja, ei mikään ottaa ja lähetä!
|
Julkaistu 6.12.2014 10.54.55
|
|
|
Julkaistu 7.12.2014 17.24.18
