HTTP-Methoden – GET vs. POST | W3Docs

HTTP (Hypertext Transfer Protocol) wurde entwickelt, um die Kommunikation zwischen Clients und einem Server zu ermöglichen. Es arbeitet nach dem Anfrage-Antwort-Modell: Der Client sendet eine Anfrage, die eine HTTP-Methode (auch HTTP-Verb genannt) festlegt, und die Methode teilt dem Server mit, welche Aktion an der Zielressource ausgeführt werden soll.

Ein HTML-<form>-Element unterstützt von Haus aus nur zwei dieser Methoden — GET und POST — über sein method-Attribut. Deshalb begegnen diese beiden HTML-Entwicklern zuerst. HTTP selbst definiert jedoch noch weitere Methoden (PUT, PATCH, DELETE, HEAD, OPTIONS, CONNECT), die Sie über JavaScript (fetch) oder Ihr Backend beim Erstellen von REST-APIs aufrufen.

Zwei wichtige Eigenschaften: Sicher und idempotent

Bevor wir uns einzelne Methoden ansehen, beschreiben zwei Begriffe, wie sich jede verhält. Sie werden auf dieser Seite und in HTTP-Spezifikationen verwendet.

Sicher — die Methode ist schreibgeschützt. Sie darf den Zustand des Servers nicht verändern. Das Abrufen einer Seite sollte niemals etwas erstellen, aktualisieren oder löschen. GET, HEAD und OPTIONS sind sicher.
Idempotent — die gleiche Anfrage einmal oder mehrfach zu senden hat die gleiche Auswirkung auf den Server. Ob man DELETE einmal oder fünfmal für eine Ressource sendet – die Ressource ist in beiden Fällen gelöscht. Sichere Methoden sind immer idempotent, aber eine Methode kann idempotent sein, ohne sicher zu sein (zum Beispiel PUT und DELETE).

Hier ist ein Vergleich der gängigen Methoden:

Methode	Sicher	Idempotent	Hat Anfrage-Body	Typische Verwendung
GET	Ja	Ja	Nein	Ressource abrufen
HEAD	Ja	Ja	Nein	Nur Header abrufen
OPTIONS	Ja	Ja	Nein	Erlaubte Methoden ermitteln / CORS-Preflight
POST	Nein	Nein	Ja	Ressource erstellen oder Daten senden
PUT	Nein	Ja	Ja	Ressource an bekannter URL ersetzen/aktualisieren
PATCH	Nein	Nicht garantiert	Ja	Teiländerung anwenden
DELETE	Nein	Ja	Meist nein	Ressource entfernen

Info

PATCH ist nicht garantiert idempotent. Abhängig davon, wie der Patch formuliert ist, kann er es sein (z. B. „status auf active setzen") oder auch nicht (z. B. „Zähler um 1 erhöhen"). Die HTTP-Spezifikation überlässt dies der Implementierung.

GET-Methode

Die GET-Methode fordert Daten von einer angegebenen Quelle an. Sie ist sicher und idempotent: Sie liest nur Daten und ändert nichts am Server. GET-Anfragen können gecacht werden und verbleiben im Browserverlauf. Sie können auch als Lesezeichen gespeichert werden.

Sie sollte niemals für sensible Daten verwendet werden, da der Query-String Teil der URL ist (die protokolliert, gecacht und als Lesezeichen gespeichert wird). GET-Anfragen haben praktische Längenbeschränkungen und sollten nur zum Abrufen von Daten verwendet werden.

Gefahr

Die Query-Strings (Name/Wert-Paare) werden in der URL der GET-Anfrage gesendet.

Beispiel eines Texteingabefelds mit der GET-Methode

<!DOCTYPE html>
<html>
  <head>
    <title>Title of the document</title>
  </head>
  <body>
    <form action="/form/submit" method="get">
      First name:
      <input type="text" name="username" placeholder="Your name" />
      <br />
      <br />
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

Probier es selbst »

POST-Methode

Die POST-Methode sendet Daten zur Verarbeitung an eine angegebene Quelle. Sie ist weder sicher noch idempotent: Sie kann den Serverzustand verändern, und das zweimalige Absenden desselben Formulars erzeugt in der Regel zwei Einträge – weshalb Browser Sie warnen, bevor POST-Daten erneut gesendet werden. Im Gegensatz zur GET-Methode werden POST-Anfragen niemals gecacht, verbleiben nicht im Browserverlauf und können nicht als Lesezeichen gespeichert werden. Außerdem unterliegen POST-Anfragen keinen URL-Längenbeschränkungen, obwohl Server in der Regel eigene Größenbeschränkungen für den Body durchsetzen.

Gefahr

Die Query-Strings (Name/Wert-Paare) werden im HTTP-Nachrichtentext der POST-Anfrage gesendet.

Beispiel eines Formulars mit der „post"-Methode

<!DOCTYPE html>
<html>
  <head>
    <title>Title of the document</title>
  </head>
  <body>
    <form action="/form/submit" method="post">
      First name:
      <input type="text" name="username" placeholder="Your name" />
      <br /><br />
      <input type="submit" value="Submit" />
    </form>
  </body>
</html>

Probier es selbst »

Vergleich von GET- und POST-Methoden

Merkmal	GET	POST
Zurück-Schaltfläche/Neu laden	Harmlos	Das Neu laden der Seite sendet die Formulardaten erneut. Der Browser muss in diesem Fall darauf hinweisen, dass die Daten erneut gesendet werden.
Als Lesezeichen speicherbar	Ja	Nein
Cachebar	Ja	Nein
Kodierungstyp	application/x-www-form-urlencoded	application/x-www-form-urlencoded oder multipart/form-data
Verlauf	Verbleibt im Browserverlauf.	Verbleibt nicht im Browserverlauf.
Datenlängenbeschränkungen	Beim Senden von Daten fügt die GET-Methode die Daten zur URL hinzu. Die URL-Länge ist begrenzt (maximale URL-Länge: 2048 Zeichen).	Hat keine URL-Längenbeschränkungen, obwohl Server in der Regel eigene Body-Größenbeschränkungen durchsetzen.
Datentypbeschränkung	Primär ASCII-Zeichen, obwohl UTF-8 über Prozent-Kodierung unterstützt wird.	Hat keine Einschränkungen. Binärdaten sind ebenfalls erlaubt.
Sicherheit	Weniger sicher als POST, da die gesendeten Daten Teil der URL sind.	POST ist sicherer als GET, da die Daten weder in der URL noch im Browserverlauf sichtbar sind. Beide übertragen Daten jedoch im Klartext über HTTP und benötigen HTTPS für tatsächliche Sicherheit.
Sichtbarkeit	Daten sind für alle in der URL sichtbar.	Zeigt keine Daten in der URL an.

Hinweis Das HTML-<form>-Element unterstützt von Haus aus nur GET und POST über sein method-Attribut. Um PUT, PATCH oder DELETE zu verwenden, sendet man die Anfrage in der Regel mit JavaScript (fetch) oder lässt das Backend-Framework die Methode überschreiben.

HEAD, OPTIONS und CONNECT

Neben GET und POST definiert HTTP noch weitere Methoden. Drei davon werden hier beschrieben; die ressourcenorientierten PUT, PATCH und DELETE folgen in eigenen Abschnitten.

Methode	Sicher	Idempotent	Beschreibung
HEAD	Ja	Ja	Identisch mit GET, aber der Server gibt nur die HTTP-Header zurück, nicht den Antwort-Body.
OPTIONS	Ja	Ja	Fragt den Server, welche Methoden und Optionen für eine Ressource verfügbar sind.
CONNECT	Nein	Nein	Stellt einen Tunnel zum Server her, wird von Proxys für HTTPS verwendet.

HEAD

HEAD funktioniert genau wie GET, aber der Server lässt den Body weg und sendet nur die Header zurück. Da es sicher und idempotent ist, eignet es sich ideal, wenn Sie Metadaten benötigen, ohne die gesamte Ressource herunterzuladen – zum Beispiel, um die Content-Length einer großen Datei vor dem Herunterladen zu prüfen oder zu testen, ob eine URL noch erreichbar ist (ihr Statuscode), ohne den Inhalt zu übertragen.

OPTIONS

OPTIONS fragt den Server, was er für eine Ressource erlaubt. Die Antwort enthält in der Regel einen Allow-Header, der die unterstützten Methoden auflistet (z. B. Allow: GET, POST, OPTIONS). Die wichtigste praktische Anwendung ist die CORS-Preflight-Anfrage: Bevor ein Browser eine ursprungsübergreifende PUT-, DELETE- oder eine Anfrage mit benutzerdefinierten Headern sendet, sendet er automatisch eine OPTIONS-Anfrage, um zu bestätigen, dass der Server den eigentlichen Aufruf erlaubt. Sie schreiben OPTIONS-Anfragen selten manuell – der Browser erledigt das für Sie.

CONNECT

CONNECT weist einen Proxy-Server an, einen transparenten TCP/IP-Tunnel zum Ziel aufzubauen, meistens damit verschlüsselter HTTPS-Verkehr ungelesen durch den Proxy geleitet werden kann. Es wird von der Infrastruktur und nicht vom Anwendungscode verwendet, daher werden Sie es so gut wie nie direkt aufrufen.

PUT-Methode

Die PUT-Methode wird hauptsächlich verwendet, um eine Ressource zu ersetzen oder zu aktualisieren. Der Client sendet die URL der Zielressource zusammen mit einem Anfrage-Body, der die vollständige, aktualisierte Darstellung dieser Ressource enthält. PUT kann auch eine Ressource erstellen, wenn der Client (nicht der Server) die URL der Ressource festlegt.

PUT ist nicht sicher, da es den Zustand auf dem Server verändert, aber es ist idempotent: Wenn Sie dieselbe PUT-Anfrage zweimal senden, befindet sich die Ressource in genau demselben Zustand wie nach einer einzigen Anfrage – der Body ersetzt vollständig, was zuvor dort war.

Das folgende Beispiel weist den Server an, den angegebenen JSON-Body als Ressource unter /users/42 zu speichern:

HTTP-Methoden – PUT-Anfrage-Beispiel

PUT /users/42 HTTP/1.1
Host: www.w3docs.com
Accept-Language: en-us
Connection: keep-alive
Content-Type: application/json
Content-Length: 54

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

Nach dem Speichern des Body könnte der Server wie folgt antworten:

HTTP-Methoden – PUT-Antwort-Beispiel

HTTP/1.1 200 OK
Date: Mon, 15 Jun 2026 14:53:57 GMT
Content-Type: application/json
Content-Length: 54
Connection: keep-alive

{
  "name": "Jane Doe",
  "email": "[email protected]"
}

PATCH-Methode

Die PATCH-Methode wird für teilweise Änderungen einer Ressource verwendet. Im Gegensatz zu PUT benötigt sie nicht die gesamte Ressource – der Body enthält nur die anzuwendenden Änderungen.

PATCH ist nicht sicher, und es ist nicht garantiert idempotent: Abhängig vom Patch-Format kann es sein oder auch nicht, dass bei Wiederholung dasselbe Ergebnis erzeugt wird. Ein Patch wie „status auf active setzen" ist idempotent, aber ein Patch wie „1 zu views addieren" ist es nicht. Kollisionen zwischen zwei PATCH-Anfragen können ebenfalls gefährlich sein, da einige Patch-Formate erwarten, Änderungen von einem gemeinsamen Basiszustand anzuwenden; andernfalls kann die Ressource beschädigt werden.

Das folgende Beispiel ändert nur das Feld email des Benutzers und lässt alle anderen Felder unberührt:

HTTP-Methoden – PATCH-Anfrage-Beispiel

PATCH /users/42 HTTP/1.1
Host: www.w3docs.com
Content-Type: application/json
Content-Length: 31

{ "email": "[email protected]" }

HTTP/1.1 200 OK
Date: Mon, 15 Jun 2026 14:53:57 GMT
Content-Type: application/json
Connection: keep-alive

DELETE-Methode

Wie der Name andeutet, entfernt diese Methode die durch eine URL identifizierte Ressource. DELETE ist nicht sicher, aber idempotent: Sobald eine Ressource gelöscht ist, führt ein erneuter DELETE-Aufruf dazu, dass sie gelöscht bleibt – der Endzustand ist derselbe. (Wiederholte Aufrufe können einen anderen Statuscode zurückgeben, z. B. 404 Not Found beim zweiten Versuch, aber der Serverzustand ändert sich nicht weiter.)

Das folgende Beispiel weist den Server an, den Benutzer unter /users/42 zu löschen:

DELETE-Anfrage-Beispiel

DELETE /users/42 HTTP/1.1
Host: www.w3docs.com
Accept-Language: en-us
Connection: keep-alive

Nach dem Löschen der Ressource antwortet der Server häufig mit 204 No Content – einem Erfolgsstatus ohne Antwort-Body:

DELETE-Antwort-Beispiel

HTTP/1.1 204 No Content
Date: Mon, 15 Jun 2026 14:53:57 GMT
Connection: keep-alive

Eine 200 OK-Antwort (optional mit einem Body, der die gelöschte Ressource beschreibt) ist ebenfalls eine gültige DELETE-Antwort. Siehe HTTP-Statusmeldungen für die vollständige Liste der Statuscodes.