Inden for programmering er POST en af mange anmodningsmetoder, der understøttes af HTTP -protokollen, der bruges på World Wide Web. POST-anmodningsmetoden er til at sende en anmodning, hvor webserveren accepterer de data, der er indesluttet i meddelelsesteksten, til opbevaring. Det bruges ofte til at uploade en fil eller indsende en udfyldt webformular .
I modsætning hertil er HTTP GET-metoden designet til at modtage information fra serveren. Som en del af en GET-anmodning kan nogle data sendes i URI-forespørgselsstrengen, hvilket f.eks. angiver søgetermer, datointervaller eller andre oplysninger, der definerer anmodningen. Som en del af en POST-anmodning kan en vilkårlig mængde data af enhver type sendes til serveren i brødteksten i anmodningsmeddelelsen. Overskriftsfelterne i en POST -anmodning angiver normalt indholdstypen .
World Wide Web og HTTP-protokollen er baseret på en række anmodningsmetoder eller "verber", herunder POST og GET, samt PUT, DELETE og en række andre. Webbrowsere bruger typisk kun GET og POST, men online REST - applikationer tvinger mange flere. POST-metoden er beregnet til at sende en repræsentation af en ny enhed til serveren, så den vil blive lagret som en underressource af ressourcen identificeret af URI'en. For eksempel for URI'en http://example.com/customers (unreachable link) , kan POST-anmodninger repræsentere nye kunder, som hver indeholder et navn, adresse, kontaktoplysninger og lignende. Webstedsudviklere har bevæget sig væk fra dette koncept af to grunde. For det første er der ingen teknisk grund til, at en URI tekstuelt beskriver de underliggende webressourcer, hvor de data, der sendes med POST-metoden, vil blive gemt. Faktisk er det mere sandsynligt, at den sidste del af URI'en beskriver webapplikationens behandlingsside og dens teknologi, såsom http://example.com/applicationform.php (dødt link) . For det andet, givet den naturlige begrænsning for de fleste webbrowsere til kun at bruge GET- eller POST-metoderne, erkendte udviklerne behovet for at tilføje flere funktioner til POST-metoden, herunder at ændre eksisterende poster og slette dem.
Forsøg på at rette op på den første mangel begyndte i 1998. Webapplikationsrammer såsom Ruby on Rails og andre har hjulpet udviklere med at levere menneskelæselige URL'er til deres brugere . Hvad angår det andet punkt, kan du skrive scripts på klientsiden eller selvstændige applikationer, der vil bruge andre HTTP-metoder, og derefter konvertere dem til en POST-metode.
Det vil sige, det kan ikke siges, at hver webformular skal indeholde en POST-metode i åbningstagget. Mange formularer bruges mere præcist til at hente information fra serveren uden at ændre på de underliggende databaser. Til sådanne søgeformularer er GET-metoden ideel.
Der er tidspunkter, hvor HTTP GET er mindre egnet, selv til at hente data. Et eksempel er, når en stor mængde data skal skrives til URL'en. Browsere og webservere kan have begrænsninger på længden af URL'er , som de behandler uden trunkering eller fejl. URL-kodning af reserverede tegn i adresse- og forespørgselsstrengen kan øge længden betydeligt, mens Apache HTTP-serveren kan håndtere op til 4000 tegn (8190 bytes) i en URL [1] , Microsoft Internet Explorer begrænser længden af enhver URL til 2048 tegn .
På samme måde bør HTTP GET ikke bruges til følsomme oplysninger såsom brugernavne og adgangskoder, som skal angives sammen med andre data for at fuldføre anmodningen. Selv med HTTPS , som forhindrer aflytning under transit, vil browserhistorier og webserverlogs sandsynligvis indeholde fulde URL'er i almindelig tekst, der kan findes, hvis systemet hackes. I disse tilfælde bruges HTTP POST.
Når en webbrowser sender en POST-anmodning med webformularelementer, er standard internetmediedatatypen application/x-www-form-urlencoded. Dette er et format til kodning af nøgleværdi-par med mulighed for dublerede nøgler. Hvert nøgle-værdi-par er adskilt med &, nøglen adskilles fra værdien med =. I nøgler og værdier erstattes mellemrum med +, og derefter, ved hjælp af URL-kodning, erstattes alle ikke-alfanumeriske tegn.
For eksempel,
Navn: Jonathan Doe Alder: 23 Formel: a + b == 13%!vil blive kodet som
Navn=Jonathan+Doe&Alder=23&Formel=a+%2B+b+%3D%3D+13+%25%21Siden HTML 4.0 kan formularer også indsende data i multipart/form som defineret i RFC 2388 (se også RFC 1867 for en tidligere eksperimentel version defineret som en udvidelse af HTML 2.0 og refereret til i HTML 3.2). Et særligt tilfælde af POST-metoden, når man får adgang til den samme side, der ejer formularen, kaldes en tilbagesendelse.
I RFC 2616 skal POST-metoden bruges til enhver kontekst, hvor anmodningen ikke er idempotent : det vil sige, at den forårsager en servertilstandsændring hver gang den udføres, såsom at sende en kommentar til et blogindlæg eller en internetafstemning. I praksis er GET-metoden ofte forbeholdt, ikke kun til idempotente handlinger, men også til nullpotente, det vil sige uden bivirkninger (i modsætning til "ingen bivirkninger ved den anden og efterfølgende anmodninger" som ved idempotente operationer). Af denne grund bruger søgemaskinewebsteder, såsom søgemaskineindeksere, typisk GET-metoden udelukkende for at forhindre automatiske anmodninger i at foretage nogen handling.
Der er dog grunde til, at POST bruges selv til idempotente anmodninger, især hvis anmodningen bruger ikke-ASCII-tegn eller er meget lang, på grund af URL-begrænsninger - GET-metodens forespørgselsstreng kan være meget lang, især når der bruges URL-kodning.