Wat zijn de belangrijkste verschillen tussen de HTTP-verzoekmethoden GET en POST?

Doel

• GET vraagt om een representatie van een bron. Volgens specificatie is het alleen-lezen: de client verwacht geen verandering in de serverstatus. RFC 9110 merkt op dat het verzenden van een body in een GET-verzoek een ongedefinieerde semantiek heeft, dus GET mag geen body bevatten.
• POST vraagt ​​de doelbron om de gegevens in de aanvraagtekst te verwerken volgens de eigen semantiek van die bron (een record maken, een formulier indienen, een bestand uploaden, enz.).

Waar de gegevens naartoe gaan

• GET bevat parameters in de URL-queryreeks (na ?, geformatteerd als key=value&...). Deze zijn zichtbaar in de adresbalk en vastgelegd in de browsergeschiedenis en serverlogboeken, en worden begrensd door een praktische URL-lengtelimiet.
• POST draagt ​​gegevens over in de verzoektekst; het type wordt gegeven door de Content-Type-header. HTML-formulieren gebruiken doorgaans application/x-www-form-urlencoded (de standaard) of multipart/form-data (voor bestanden). Er is geen vaste limiet voor de grootte op protocolniveau, maar servers en proxy's configureren hun eigen maxima (bijvoorbeeld Nginx client_max_body_size).

Eigenschappen volgens RFC 9110

• Veilig: GET is veilig (alleen-lezen); POST is dat niet.
• Idempotent: een verzoek is idempotent als het N keer maken ervan hetzelfde effect heeft op de serverstatus als het één keer maken ervan. GET is idempotent; POST is dat niet. Als u het herhaalt, kunnen er duplicaten ontstaan, zoals twee identieke bestellingen. Idempotent is niet hetzelfde als veilig (PUT en DELETE zijn idempotent maar niet veilig), en het zegt niets over de identieke antwoordtekst.
• Cachebaar: GET-antwoorden kunnen standaard in de cache worden opgeslagen; POST-antwoorden kunnen alleen in de cache worden opgeslagen als ze expliciete versheidsinformatie en een bijpassende Content-Location-header bevatten, wat in de praktijk zelden voorkomt.

Praktische implicaties

• Gebruik GET voor ophalen en navigeren; resultaten kunnen veilig worden herhaald, van een bladwijzer worden voorzien en vooraf worden opgehaald, en het vernieuwen van een GET-pagina is onschadelijk.
• Gebruik POST voor statusveranderende acties en voor het verzenden van gevoelige of grote payloads. Bij het vernieuwen of terug navigeren naar een POST-pagina wordt de waarschuwing "formulier opnieuw indienen bevestigen" van de browser geactiveerd.
• Stuur nooit wachtwoorden via GET; ze komen terecht in de URL, logs en geschiedenis. Dit is hygiëne, geen encryptie: HTTPS codeert zowel de URL als de hoofdtekst tijdens de overdracht, maar de URL wordt nog steeds geregistreerd.

Veel voorkomende vervolgacties

• Veilige methoden zijn GET, HEAD, OPTIONS; idempotente methoden zijn GET, HEAD, PUT, DELETE; POST is geen van beide.
• Beide methoden worden ondersteund door HTML-formulieren (het attribuut method).
• "Veilig" in de RFC-zin betekent geen statusverandering, geen gegevensbescherming.
• POST-idempotentie op applicatieniveau wordt vaak afgedwongen met behulp van idempotentiesleutels.