Ohjelmoinnissa POST on yksi monista pyyntömenetelmistä , joita World Wide Webissä käytetty HTTP -protokolla tukee . POST-pyyntömenetelmä on pyynnön lähettäminen, jossa verkkopalvelin hyväksyy viestin runkoon sisältyvät tiedot tallennettavaksi. Sitä käytetään usein tiedoston lataamiseen tai täytetyn verkkolomakkeen lähettämiseen .
Sitä vastoin HTTP GET -menetelmä on suunniteltu vastaanottamaan tietoja palvelimelta. Osana GET-pyyntöä URI-kyselymerkkijonossa voidaan välittää joitakin tietoja, jotka osoittavat esimerkiksi hakutermejä, ajanjaksoja tai muita pyynnön määritteleviä tietoja. Osana POST-pyyntöä palvelimelle voidaan lähettää mielivaltainen määrä minkä tahansa tyyppistä dataa pyyntösanoman rungossa. POST-pyynnön otsikkokentät osoittavat yleensä sisältötyypin .
World Wide Web ja HTTP-protokolla perustuvat useisiin pyyntömenetelmiin tai "verbeihin", mukaan lukien POST ja GET sekä PUT, DELETE ja monet muut. Web-selaimet käyttävät tyypillisesti vain GET- ja POST-käyttöä, mutta online -REST- sovellukset pakottavat paljon enemmän. POST-menetelmä on tarkoitettu lähettämään uuden entiteetin esitys palvelimelle, jotta se tallennetaan URI:n tunnistaman resurssin aliresurssiksi. Esimerkiksi URI http://example.com/customers (unreachable link) osalta POST-pyynnöt voivat edustaa uusia asiakkaita, joista jokainen sisältää nimen, osoitteen, yhteystiedot ja vastaavat. Verkkosivustojen kehittäjät ovat siirtyneet pois tästä käsitteestä kahdesta syystä. Ensinnäkin URI:lla ei ole teknistä syytä kuvailla tekstin alla olevia verkkoresursseja, joihin POST-menetelmällä lähetetyt tiedot tallennetaan. Itse asiassa URI:n viimeinen osa kuvaa todennäköisemmin verkkosovelluksen käsittelysivua ja sen tekniikkaa, kuten http://example.com/applicationform.php (kuollut linkki) . Toiseksi, koska useimpien verkkoselaimien luonnollinen rajoitus käyttää vain GET- tai POST-menetelmiä, kehittäjät ymmärsivät tarpeen lisätä POST-menetelmään uusia ominaisuuksia, mukaan lukien olemassa olevien merkintöjen muokkaaminen ja niiden poistaminen.
Ensimmäisen puutteen korjaaminen aloitettiin vuonna 1998. Verkkosovelluskehykset , kuten Ruby on Rails ja muut, ovat auttaneet kehittäjiä tarjoamaan ihmisille luettavia URL-osoitteita käyttäjilleen . Mitä tulee toiseen kohtaan, voit kirjoittaa asiakaspuolen komentosarjoja tai itsenäisiä sovelluksia, jotka käyttävät muita HTTP-menetelmiä, ja muuntaa ne sitten POST-menetelmäksi.
Ei siis voida sanoa, että jokaisen verkkolomakkeen pitäisi sisältää POST-menetelmä avaustunnisteessa. Monia lomakkeita käytetään tarkemmin tietojen hakemiseen palvelimelta muuttamatta taustalla olevia tietokantoja. Tällaisille hakulomakkeille GET-menetelmä on ihanteellinen.
Joskus HTTP GET ei sovellu jopa tietojen hankkimiseen. Esimerkki on, kun URL-osoitteeseen on kirjoitettava suuri määrä dataa. Selaimilla ja verkkopalvelimilla voi olla rajoituksia niiden URL-osoitteiden pituudelle, jotka ne käsittelevät ilman katkaisua tai virheitä. URL-koodatut varatut merkit osoitteessa ja kyselymerkkijonossa voivat pidentää pituutta huomattavasti, kun taas Apache HTTP Server pystyy käsittelemään jopa 4000 merkkiä (8190 tavua) URL-osoitteessa [1] , Microsoft Internet Explorer rajoittaa minkä tahansa URL-osoitteen pituuden 2048:aan. hahmoja .
Samoin HTTP GET:iä ei tule käyttää arkaluontoisille tiedoille, kuten käyttäjätunnuksille ja salasanoille, jotka on annettava muiden tietojen kanssa pyynnön suorittamiseksi. Jopa HTTPS :llä , joka estää salakuuntelun siirron aikana, selainhistoriat ja verkkopalvelimen lokit sisältävät todennäköisesti täydelliset URL-osoitteet pelkkänä tekstinä, joka löytyy, jos järjestelmään murtaudutaan. Näissä tapauksissa käytetään HTTP POSTia.
Kun verkkoselain lähettää POST-pyynnön verkkolomakeelementeillä, oletusarvoinen Internet-mediatietotyyppi on application/x-www-form-urlencoded. Tämä on muoto avain-arvo-parien koodaamiseen mahdollisten avainten kaksoiskappaleiden kanssa. Jokainen avain-arvo-pari on erotettu merkillä &, avain erotetaan arvosta merkillä =. Avaimissa ja arvoissa välilyönnit korvataan +merkillä , ja sitten URL-koodausta käyttämällä korvataan kaikki ei-aakkosnumeeriset merkit.
Esimerkiksi,
Nimi: Jonathan Doe Ikä: 23 Kaava: a + b == 13%!koodataan muodossa
Nimi=Jonathan+Doe&Age=23&Formula=a+%2B+b+%3D%3D+13+%25%21HTML 4.0:sta lähtien lomakkeet voivat lähettää tietoja myös moniosaisessa muodossa RFC 2388 :n mukaisesti (katso myös RFC 1867 aikaisemmasta kokeellisesta versiosta, joka on määritelty HTML 2.0:n laajennukseksi ja johon viitataan HTML 3.2:ssa). POST-menetelmän erikoistapausta, kun käytetään samaa sivua, joka omistaa lomakkeen, kutsutaan takaisinlähetykseksi.
RFC 2616 : ssa POST-menetelmää on käytettävä kaikissa konteksteissa, joissa pyyntö ei ole idempotentti : eli se aiheuttaa palvelimen tilan muutoksen joka kerta, kun se suoritetaan, kuten kommentin lähettäminen blogitekstiin tai Internet-äänestys. Käytännössä GET-menetelmä on usein varattu, ei vain idempotenteille toimille, vaan myös nollapotenteille eli ilman sivuvaikutuksia (toisin kuin "ei sivuvaikutuksia toisessa ja myöhemmissä pyynnöissä" kuten idempotenteissa toimissa). Tästä syystä hakukonesivustot, kuten hakukoneiden indeksoijat, käyttävät yleensä GET-menetelmää yksinomaan estääkseen automaattisia pyyntöjä tekemästä mitään.
On kuitenkin olemassa syitä, miksi POST:ia käytetään myös idempotenteihin pyyntöihin, varsinkin jos pyyntö käyttää ei-ASCII-merkkejä tai on erittäin pitkä, URL-rajoitusten vuoksi - GET-menetelmän kyselymerkkijono voi olla hyvin pitkä, varsinkin käytettäessä URL-koodausta.