Was sind die Hauptunterschiede zwischen den HTTP-Anfragemethoden GET und POST?

Zweck

• GET fordert eine Darstellung einer Ressource an. Laut Spezifikation ist es schreibgeschützt: Der Client erwartet keine Änderung des Serverstatus. RFC 9110 weist darauf hin, dass das Senden eines Textes in einer GET-Anfrage eine undefinierte Semantik hat, sodass GET keinen Text enthalten sollte.
• POST fordert die Zielressource auf, die im Anforderungstext enthaltenen Daten gemäß der eigenen Semantik dieser Ressource zu verarbeiten (einen Datensatz erstellen, ein Formular senden, eine Datei hochladen usw.).

Wohin die Daten gehen

• GET trägt Parameter in der URL-Abfragezeichenfolge (nach ? , formatiert als key=value&... ). Diese sind in der Adressleiste sichtbar, werden im Browserverlauf und in den Serverprotokollen aufgezeichnet und unterliegen einer praktischen URL-Längenbeschränkung.
• POST trägt Daten im Anfragetext; Der Typ wird durch den Content-Type-Header angegeben. HTML-Formulare verwenden normalerweise application/x-www-form-urlencoded (Standard) oder multipart/form-data (für Dateien). Es gibt keine feste Größenbeschränkung auf Protokollebene, aber Server und Proxys konfigurieren ihre eigenen Maximalwerte (z. B. Nginx client_max_body_size ).

Eigenschaften gemäß RFC 9110

• Sicher: GET ist sicher (schreibgeschützt); POST ist nicht.
• Idempotent: Eine Anfrage ist idempotent, wenn die N-malige Ausführung dieselbe Auswirkung auf den Serverstatus hat wie die einmalige Ausführung. GET ist idempotent; Bei POST ist dies nicht der Fall – eine Wiederholung kann zu Duplikaten führen, z. B. zu zwei identischen Bestellungen. Idempotent ist nicht dasselbe wie sicher (PUT und DELETE sind idempotent, aber nicht sicher), und es sagt nichts darüber aus, dass der Antworttext identisch ist.
• Cacheable: GET-Antworten sind standardmäßig zwischenspeicherbar; POST-Antworten können nur zwischengespeichert werden, wenn sie explizite Aktualitätsinformationen und einen passenden Content-Location-Header enthalten, was in der Praxis selten vorkommt.

Praktische Implikationen

• Verwenden Sie GET zum Abrufen und Navigieren. Ergebnisse können sicher wiederholt, mit Lesezeichen versehen und vorab abgerufen werden, und das Aktualisieren einer GET-Seite ist harmlos.
• Verwenden Sie POST für Aktionen zur Zustandsänderung und zum Senden sensibler oder großer Nutzlasten. Das Aktualisieren oder Zurücknavigieren einer POST-Seite löst die Browserwarnung „Formular erneut senden bestätigen“ aus.
• Senden Sie Passwörter niemals per GET – sie würden in der URL, in den Protokollen und im Verlauf landen. Dies dient der Hygiene, nicht der Verschlüsselung: HTTPS verschlüsselt sowohl die URL als auch den Text während der Übertragung, die URL wird jedoch weiterhin protokolliert.

Häufige Folgemaßnahmen

• Sichere Methoden sind GET, HEAD, OPTIONS; idempotente Methoden sind GET, HEAD, PUT, DELETE; POST ist weder das eine noch das andere.
• Beide Methoden werden von HTML-Formularen unterstützt (das Attribut method).
• „Sicher“ im RFC-Sinn bedeutet keine Zustandsänderung, keinen Datenschutz.
• POST-Idempotenz auf Anwendungsebene wird häufig mithilfe von Idempotenzschlüsseln erzwungen.