A programozásban a POST egyike a sok kérési módszernek, amelyet a világhálón használt HTTP protokoll támogat. A POST kérési módszer olyan kérés küldésére szolgál, ahol a webszerver elfogadja az üzenettörzsben foglalt adatokat tárolásra. Gyakran használják fájl feltöltésére vagy kitöltött webes űrlap beküldésére .
Ezzel szemben a HTTP GET módszert úgy tervezték, hogy információkat fogadjon a szervertől. A GET-kérés részeként egyes adatok átadhatók az URI lekérdezési karakterláncban, jelezve például a keresési kifejezéseket, dátumtartományokat vagy a kérést meghatározó egyéb információkat. A POST kérés részeként tetszőleges mennyiségű adat küldhető a szervernek a kérés üzenet szövegében. A POST kérések fejlécmezői általában a tartalom típusát jelzik .
A World Wide Web és a HTTP protokoll számos kérési módszeren vagy "igén" alapul, beleértve a POST-ot és a GET-et, valamint a PUT-t, a DELETE-t és még sok mást. A webböngészők általában csak a GET-et és a POST-ot használják, de az online REST - alkalmazások sokkal többet használnak. A POST metódus célja egy új entitás reprezentációjának elküldése a kiszolgálónak, így az az URI által azonosított erőforrás al-erőforrásaként kerül tárolásra. Például a http://example.com/customers (unreachable link) URI esetében a POST kérések új ügyfeleket jelenthetnek, mindegyik tartalmazhat nevet, címet, elérhetőségi adatokat és hasonlókat. A webhelyfejlesztők két okból is eltávolodtak ettől a koncepciótól. Először is, nincs technikai oka annak, hogy az URI szövegesen írja le a mögöttes webes erőforrásokat, ahol a POST metódussal küldött adatok tárolásra kerülnek. Valójában az URI utolsó része nagyobb valószínűséggel írja le a webalkalmazás feldolgozó oldalát és technológiáját, például a http://example.com/applicationform.php (halott link) . Másodszor, tekintettel arra, hogy a legtöbb webböngésző csak a GET vagy POST metódusokat használja, a fejlesztők felismerték, hogy további funkciókat kell hozzáadni a POST módszerhez, beleértve a meglévő bejegyzések módosítását és törlését.
Az első hiányosság kijavítására 1998-ban kezdődtek a kísérletek. Az olyan webalkalmazás- keretrendszerek , mint a Ruby on Rails és mások, segítettek a fejlesztőknek abban, hogy ember által olvasható URL-eket biztosítsanak felhasználóiknak . Ami a második pontot illeti, írhat kliensoldali szkripteket vagy önálló alkalmazásokat, amelyek más HTTP-metódusokat használnak, majd konvertálják azokat POST metódussá.
Vagyis nem lehet azt mondani, hogy minden webes űrlapnak tartalmaznia kell egy POST metódust a nyitó címkében. Sok űrlapot pontosabban használnak az információk lekérésére a szerverről anélkül, hogy megváltoztatnák az alapul szolgáló adatbázisokat. Az ilyen keresési formákhoz a GET módszer az ideális.
Vannak esetek, amikor a HTTP GET még adatszerzésre is kevésbé alkalmas. Példa erre, amikor nagy mennyiségű adatot kell írni az URL-re. A böngészők és webszerverek korlátozhatják a csonkolás vagy hiba nélkül feldolgozott URL-címek hosszát. Az URL-kódolás fenntartott karakterek a címben és a lekérdezési karakterláncban nagymértékben megnövelhetik a hosszt, míg az Apache HTTP Server akár 4000 karaktert (8190 bájt) is képes kezelni egy URL-ben [1] , a Microsoft Internet Explorer 2048-ra korlátozza bármely URL hosszát. karakterek .
Hasonlóképpen, a HTTP GET nem használható érzékeny információkhoz, például felhasználónevekhez és jelszavakhoz, amelyeket a kérés teljesítéséhez más adatokkal együtt meg kell adni. Még a HTTPS használatával is , amely megakadályozza a lehallgatást az átvitel során, a böngészőelőzmények és a webszerver-naplók valószínűleg teljes URL-eket tartalmaznak egyszerű szövegben, amelyek megtalálhatók a rendszer feltörése esetén. Ezekben az esetekben a HTTP POST használatos.
Amikor egy webböngésző POST kérést küld webes űrlap elemekkel, az alapértelmezett internetes média adattípus a application/x-www-form-urlencoded. Ez a formátum a kulcs-érték párok kódolására szolgál, a kulcsok megkettőzésének lehetőségével. Az egyes kulcs-érték párokat &, a kulcsot pedig az értéktől választja el =. A kulcsokban és értékekben a szóközöket helyettesíti a +, majd az URL-kódolás használatával minden nem alfanumerikus karakter lecserélődik.
Például,
Név: Jonathan Doe Kor: 23 Képlet: a + b == 13%!ként lesz kódolva
Név=Jonathan+Doe&Age=23&Formula=a+%2B+b+%3D%3D+13+%25%21A HTML 4.0 óta az űrlapok az RFC 2388 -ban meghatározott többrészes/formátumú adatokat is beküldhetnek (lásd még az RFC 1867 -et a HTML 2.0 kiterjesztéseként meghatározott, és a HTML 3.2-ben hivatkozott korábbi kísérleti verzióhoz). A POST metódus egy speciális esetét, amikor ugyanazt az oldalt éri el, amelyik az űrlap tulajdonosa, visszaküldésnek nevezzük.
Az RFC 2616 -ban a POST metódust kell használni minden olyan környezetben, amelyben a kérés nem idempotens : azaz a szerver állapotának változását okozza minden egyes végrehajtáskor, például ha megjegyzést tesz közzé egy blogbejegyzéshez vagy egy internetes szavazást. A gyakorlatban a GET metódust gyakran fenntartják, nem csak az idempotens műveletekre, hanem a nullpotensekre is, azaz mellékhatások nélkül (szemben a "nincs mellékhatás a második és az azt követő kérésekre", mint az idempotens műveleteknél). Emiatt a keresőmotor-webhelyek, például a keresőmotor-indexelők, általában kizárólag a GET-módszert használják, hogy megakadályozzák, hogy az automatizált kérések bármilyen műveletet hajtsanak végre.
Vannak azonban okai annak, hogy a POST-ot még idempotens kérések esetén is használják, különösen, ha a kérés nem ASCII karaktereket használ, vagy nagyon hosszú, az URL-korlátozások miatt - a GET metódus lekérdezési karakterlánca nagyon hosszú lehet, különösen URL-kódolás használata esetén.