HTTP definē dažādus veidus, kā mijiedarboties ar serveri, un ir 4 pamatmetodes, proti, GET, POST, PUT un DELETE. URL pilns nosaukums ir resursu deskriptors, mēs to varam domāt šādi: URL adrese, to izmanto, lai aprakstītu resursu tīklā, un GET, POST, PUT, DELETE HTTP atbilst četrām šī resursa pārbaudes, modificēšanas, pievienošanas un dzēšanas operācijām. Šajā brīdī jums vajadzētu būt vispārējai izpratnei, GET parasti tiek izmantots, lai iegūtu / vaicātu resursu informāciju, bet POST parasti tiek izmantots, lai atjauninātu resursu informāciju.
1. Saskaņā ar HTTP specifikāciju GET tiek izmantots informācijas izguvei, un tam jābūt drošam un idempotentam.
(1). Tā sauktā drošība nozīmē, ka operācija tiek izmantota, lai iegūtu informāciju, nevis to modificētu. Citiem vārdiem sakot, GET pieprasījumiem parasti nevajadzētu būt blakusparādībām. Tas nozīmē, ka tas iegūst tikai resursu informāciju, tāpat kā datu bāzes vaicājums, un nemainīs, nepievienos datus un neietekmēs resursa stāvokli.
* Piezīme: Drošības nozīme šeit attiecas tikai uz nemodificētu informāciju.
(2). idempotent nozīmē, ka vairākiem pieprasījumiem uz vienu un to pašu URL vajadzētu atgriezt vienu un to pašu rezultātu.
Tomēr praktiskā piemērošanā iepriekš minētie divi noteikumi nav tik stingri. Citu cilvēku rakstu citēšanas piemēri: Piemēram, ziņu vietnes sākumlapa tiek pastāvīgi atjaunināta. Lai gan otrais pieprasījums atgriež citu ziņu partiju, operācija joprojām tiek uzskatīta par drošu un idempotentu, jo tā vienmēr atgriež pašreizējās ziņas. Būtībā, ja mērķis ir tas, ka, atverot saiti, lietotājs var būt pārliecināts, ka resurss nav mainīts no viņa viedokļa.
2. Saskaņā ar HTTP specifikāciju POST ir pieprasījums, kas var modificēt servera resursu. Turpinot citēt iepriekš minēto piemēru: Joprojām ziņas Kā piemēru ņemiet vietni, lasītājiem vajadzētu ievietot savus komentārus par ziņām, jo vietnes resursi pēc komentāra iesniegšanas vai resursu modificēšanas ir atšķirīgi.
Iepriekš minētais aptuveni apspriež dažus GET un POST principus HTTP specifikācijā. Tomēr daudzi cilvēki, to faktiski darot, neievēro HTTP specifikāciju, kas var izraisīt daudzus šīs problēmas iemeslus, piemēram:
1. Daudzi cilvēki izmanto GET, lai atjauninātu resursus, jo viņiem ir jādodas uz FORM, lai izmantotu POST, kas būs nedaudz apgrūtinoši.
2. Resursu pievienošanas, dzēšanas, modificēšanas un pārbaudes darbību faktiski var pabeigt, izmantojot GET / POST, bez nepieciešamības izmantot PUT un DELETE.
3. Vēl viens ir tas, ka agrīnie Web MVC ietvaru dizaineri apzināti neizturējās pret URL kā abstraktiem resursiem, tāpēc nopietna problēma ir tā, ka tradicionālā Web MVC sistēma būtībā atbalsta tikai divas HTTP metodes, GET un POST, bet neatbalsta PUT un DELETE metodes.
* Īss MVC skaidrojums: MVC sākotnēji pastāvēja darbvirsmas programmā, M attiecas uz datu modeli, V attiecas uz lietotāja interfeisu un C attiecas uz kontrolieri. MVC izmantošanas mērķis ir atdalīt M un V ieviešanas kodu, lai viena un tā pati programma varētu izmantot dažādus attēlojumus.
Iepriekš minētie 3 punkti parasti apraksta veco stilu (bez stingras HTTP specifikācijas ievērošanas), attīstoties arhitektūrai, tagad ir REST (Representational State Transfer), jauns stils, kas atbalsta HTTP specifikāciju.
Runājot par galveno problēmu, apskatīsim atšķirību starp GET un POST no virsmas parādības:
1. GET pieprasījuma dati tiks pievienoti URL (tas ir, dati tiek ievietoti HTTP protokola galvenē) un ? Sadaliet URL un pārsūtiet datus, un parametri ir savienoti ar &, piemēram: login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD. Ja dati ir angļu valodas burti / cipari, nosūtiet tos tādus, kādi tie ir, ja tas ir atstarpe, konvertējiet to uz +, ja tas ir ķīniešu / citas rakstzīmes, tad tieši šifrējiet virkni ar BASE64, lai iegūtu paraugu, piemēram: %E4%BD%A0%E5%A5%BD, kur XX %XX ir ASCII, ko attēlo simbols heksadecimālajā daļā.
POST ievieto iesniegtos datus HTTP paketes pamattekstā.
2. "Maksimālais datu skaits, kas iesniegts ar GET metodi, var būt tikai 1024 baiti, teorētiski POST nav ierobežojumu, un var pārsūtīt lielu datu apjomu, līdz 80 KB IIS4 un 100 KB IIS5"??!
Iepriekš minētais teikums ir novirzīts no citiem rakstiem, patiesībā ir nepareizi un neprecīzi teikt šo:
(1). Pirmkārt, "ar GET metodi iesniegtie dati var būt tikai 1024 baiti", jo GET iesniedz datus, izmantojot URL, tāpēc datu apjoms, ko var iesniegt GET, ir tieši saistīts ar URL garumu. Faktiski URL nav augšējā parametru ierobežojuma, un HTTP protokola specifikācija neierobežo URL garumu. Šis ierobežojums ir ierobežojums, ko nosaka konkrēta pārlūkprogramma un serveris. IE URL garuma ierobežojums ir 2083 baiti (2K+35). Citām pārlūkprogrammām, piemēram, Netscape, FireFox utt., Nav teorētiska garuma ierobežojuma, un tā ierobežojums ir atkarīgs no operētājsistēmas atbalsta.
Ņemiet vērā, ka tas ierobežo visu URL garumu, ne tikai parametra vērtības datu garumu. [Skatīt 5. atsauci]
(2). Teorētiski POST nav lieluma ierobežojuma, un HTTP protokola specifikācijai nav lieluma ierobežojuma, un ir neprecīzi teikt, ka "POST datiem ir lieluma ierobežojums 80K / 100K", un POST datiem nav ierobežojumu, un tā ir servera apstrādātāja apstrādes jauda, kas spēlē ierobežojošu lomu.
ASP programmām, apstrādājot katru veidlapas lauku, objektam Pieprasījums ir 100K datu garuma ierobežojums. Bet ar Request.BinaryRead šāda ierobežojuma nav.
Paplašinot to, IIS 6.0 Microsoft ir palielinājusi ierobežojumus drošības apsvērumu dēļ. Mums jāpievērš uzmanība arī:
1). IIS 6.0 pēc noklusējuma ir ne vairāk kā 200 KB ASP POST datu, un ierobežojums ir 100 KB katram veidlapas laukam.
2). IIS 6.0 augšupielādes failu noklusējuma lielums ir 4 MB.
3). IIS 6.0 noklusējuma maksimālā pieprasījuma galvene ir 16 KB.
Šie ierobežojumi nebija pieejami pirms IIS 6.0. [Skatīt 5. atsauci]
Tātad iepriekš minētie 80K un 100K var būt tikai noklusējuma vērtības (piezīme: es vēl neesmu apstiprinājis IIS4 un IIS5 parametrus), bet jūs noteikti varat tos iestatīt pats. Tā kā šo parametru noklusējuma vērtības katrā IIS versijā ir atšķirīgas, detalizētu informāciju skatiet attiecīgajā IIS konfigurācijas dokumentā.
3. ASP serveris izmanto Request.QueryString, lai iegūtu GET pieprasījuma parametru, un Request.Form, lai iegūtu POST pieprasījuma parametru. JSP izmantojiet request.getParameter(\"XXXX\"), lai to iegūtu, lai gan jsp ir arī request.getQueryString() metode, bet to ir grūtāk izmantot, piemēram: nosūtiet test.jsp?name=hyddd&password=hydddd un izmantojiet request.getQueryString(), lai iegūtu :name= hyddd&password=hyddd。 PHP varat izmantot _GET un _POST USD, lai iegūtu datus attiecīgi no GET un POST, savukārt _REQUEST USD var iegūt datus gan no GET, gan POST pieprasījumiem. Ir vērts atzīmēt, ka ir slēptas briesmas, izmantojot pieprasījumu JSP un $ _REQUEST PHP, kas tiks apkopots rakstā nākamreiz.
4.POST ir drošāks nekā GET. Piezīme: Šeit minētais nodrošinājums nav tāds pats jēdziens kā "drošība", kas minēts iepriekš minētajā GET. Piemēram, ja iesniedzat datus, izmantojot GET, jūsu lietotājvārds un parole URL parādīsies vienkāršā tekstā, jo (1) pārlūkprogramma var saglabāt pieteikšanās lapu, (2) citi apskatīs pārlūkprogrammas vēsturi, lai citi varētu iegūt jūsu kontu un paroli viltojumu uzbrukums.
Rezumējot, Get ir pieprasījums pieprasīt datus no servera, savukārt Post ir pieprasījums iesniegt datus serverī, FORM, Method noklusējums ir "GET", būtībā GET un POST ir tikai dažādi sūtīšanas mehānismi, nevis viens ņem un nosūta vienu!
|
Publicēts 06.12.2014 10:54:55
|
|
|
Publicēts 07.12.2014 17:24:18
