Inom programmering är POST en av många förfrågningsmetoder som stöds av HTTP -protokollet som används på World Wide Web. POST-förfrågningsmetoden är för att skicka en förfrågan där webbservern accepterar data som finns inkluderade i meddelandekroppen för lagring. Det används ofta för att ladda upp en fil eller skicka in ett ifyllt webbformulär .
Däremot är HTTP GET-metoden utformad för att ta emot information från servern. Som en del av en GET-begäran kan vissa data skickas i URI-frågesträngen, som t.ex. indikerar söktermer, datumintervall eller annan information som definierar begäran. Som en del av en POST-begäran kan en godtycklig mängd data av vilken typ som helst skickas till servern i meddelandets brödtext. Rubrikfälten i en POST-förfrågan anger vanligtvis innehållstypen .
World Wide Web och HTTP-protokollet är baserade på ett antal begäransmetoder eller "verb", inklusive POST och GET, samt PUT, DELETE och ett antal andra. Webbläsare använder vanligtvis bara GET och POST, men online REST - applikationer tvingar fram många fler. POST-metoden är avsedd att skicka en representation av en ny entitet till servern så att den kommer att lagras som en underresurs till resursen identifierad av URI:n. Till exempel, för URI:n http://example.com/customers (otillgänglig länk) kan POST-förfrågningar representera nya kunder, som var och en innehåller ett namn, adress, kontaktinformation och liknande. Webbplatsutvecklare har gått bort från detta koncept av två anledningar. För det första finns det inget tekniskt skäl för en URI att textmässigt beskriva de underliggande webbresurserna där data som skickas med POST-metoden kommer att lagras. Det är faktiskt mer sannolikt att den sista delen av URI:n beskriver webbapplikationens bearbetningssida och dess teknologi, till exempel http://example.com/applicationform.php (död länk) . För det andra, med tanke på den naturliga begränsningen för de flesta webbläsare att bara använda GET- eller POST-metoderna, insåg utvecklarna behovet av att lägga till fler funktioner till POST-metoden, inklusive att ändra befintliga poster och ta bort dem.
Försöken att rätta till den första bristen började 1998. Webbapplikationsramverk som Ruby on Rails och andra har hjälpt utvecklare att tillhandahålla mänskliga läsbara webbadresser till sina användare . När det gäller den andra punkten kan du skriva skript på klientsidan eller fristående applikationer som använder andra HTTP-metoder och sedan konvertera dem till en POST-metod.
Det vill säga, det kan inte sägas att varje webbformulär måste innehålla en POST-metod i öppningstaggen. Många formulär används mer exakt för att hämta information från servern, utan att ändra de underliggande databaserna. För sådana sökformulär är GET-metoden idealisk.
Det finns tillfällen då HTTP GET är mindre lämpligt även för att hämta data. Ett exempel är när en stor mängd data behöver skrivas till URL:en. Webbläsare och webbservrar kan ha begränsningar för längden på webbadresser som de bearbetar utan trunkering eller fel. URL-kodning av reserverade tecken i adress- och frågesträngen kan avsevärt öka längden, medan Apache HTTP-servern kan hantera upp till 4000 tecken (8190 byte) i en URL [1] , Microsoft Internet Explorer begränsar längden på vilken URL som helst till 2048 tecken .
På samma sätt bör HTTP GET inte användas för känslig information som användarnamn och lösenord, som måste tillhandahållas tillsammans med annan data för att fullfölja begäran. Även med HTTPS , som förhindrar avlyssning under överföring, innehåller webbläsarhistorik och webbserverloggar sannolikt fullständiga webbadresser i vanlig text som kan hittas om systemet hackas. I dessa fall används HTTP POST.
När en webbläsare skickar en POST-begäran med webbformulärelement är standarddatatypen för internetmedia application/x-www-form-urlencoded. Detta är ett format för kodning av nyckel-värdepar med möjlighet till dubbletter av nycklar. Varje nyckel-värdepar separeras med &, nyckeln separeras från värdet med =. I nycklar och värden ersätts mellanslag med +, och sedan, med hjälp av URL-kodning, ersätts alla icke-alfanumeriska tecken.
Till exempel,
Namn: Jonathan Doe Ålder: 23 Formel: a + b == 13%!kommer att kodas som
Namn=Jonathan+Doe&Age=23&Formula=a+%2B+b+%3D%3D+13+%25%21Sedan HTML 4.0 kan formulär också skicka data i flera delar/form enligt definitionen i RFC 2388 (se även RFC 1867 för en tidigare experimentell version definierad som en förlängning av HTML 2.0 och refererad till i HTML 3.2). Ett specialfall av POST-metoden när man kommer åt samma sida som äger formuläret kallas en återsändning.
I RFC 2616 måste POST-metoden användas för alla sammanhang där begäran inte är idempotent : det vill säga, den orsakar en servertillståndsändring varje gång den exekveras, som att posta en kommentar på ett blogginlägg eller en internetomröstning. I praktiken är GET-metoden ofta reserverad, inte bara för idempotenta handlingar, utan även för nullpotenta sådana, det vill säga utan biverkningar (till skillnad från "inga biverkningar på den andra och efterföljande begäran" som vid idempotenta operationer). Av denna anledning använder sökmotorwebbplatser, såsom sökmotorindexerare, vanligtvis GET-metoden uteslutande för att förhindra automatiska förfrågningar från att vidta några åtgärder.
Det finns dock anledningar till varför POST används även för idempotenta förfrågningar, speciellt om begäran använder icke-ASCII-tecken eller är mycket lång, på grund av URL-begränsningar - GET-metodens frågesträng kan vara mycket lång, speciellt när man använder URL-kodning.