GET

Verwendung

Eine GET-Anfrage ruft Daten ab, ohne den Serverzustand zu verändern. Inhalte im Anfrage-Body haben keine allgemein definierte Semantik; die gesamte Abfrage wird über die Ziel-URI und die Header ausgedrückt. Antworten sind standardmäßig zwischenspeicherbar, wodurch GET die Grundlage des Web-Cachings bildet.

GET ist die Standardmethode des Browsers für Navigation, Linkklicks und Formularübermittlungen ohne method-Attribut.

Die HTTP-Spezifikation verbietet einen Body in GET-Anfragen nicht, aber die Semantik eines solchen Bodys ist undefiniert. Browser und die Fetch API entfernen Bodys aus GET-Anfragen. Viele Server und Proxys ignorieren oder verwerfen sie. Sich auf einen Body in einer GET-Anfrage zu verlassen, ist für die Interoperabilität nicht sicher.

Eigenschaften

Da GET sicher und idempotent ist, liefert dieselbe Anfrage auch bei mehrfachem Senden dasselbe Ergebnis und verändert die Ressource nicht. Browser, Crawler und Proxys verlassen sich alle auf diese Garantie.

Bedingtes GET

Eine GET-Anfrage wird bedingt, sobald einer oder mehrere Validator-Header vorhanden sind: If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since oder If-Range. Der Server wertet die Bedingung aus und liefert die vollständige Repräsentation nur dann zurück, wenn die Bedingung erfüllt ist.

Teilweises GET

Durch die Angabe eines Range-Headers wird aus einem GET eine Teilanfrage. Der Server gibt nur den angeforderten Bytebereich mit dem Status 206 zurück. Der Status 416 zeigt an, dass der Bereich nicht erfüllbar ist. Server, die Range-Anfragen nicht unterstützen, antworten mit 200 und dem vollständigen Body.

Teilweises GET ist nützlich, um unterbrochene Downloads fortzusetzen und große Dateien segmentweise zu streamen.

Einfaches GET

Eine minimale GET-Anfrage ruft die Wurzelressource ab. Der Server liefert 200 mit der vollständigen Repräsentation zurück.

Anfrage

GET / HTTP/1.1
Host: example.com

Antwort

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1256

<!doctype html>
<html>...

Bedingtes GET

Diese Anfrage enthält If-Modified-Since, sodass der Server den Body nur dann zurückgibt, wenn sich die Ressource seit dem angegebenen Datum geändert hat. Eine unveränderte Ressource führt zu einem 304 ohne Body.

Anfrage

GET / HTTP/1.1
Host: example.com
If-Modified-Since: Sat, 01 Jan 2022 12:00:00 GMT

Antwort (nicht geändert)

HTTP/1.1 304 Not Modified
ETag: "abc123"

Teilweises GET

Der Range-Header fordert nur die ersten 512 Bytes an. Der Server antwortet mit 206 und einem Content-Range-Header, der das zurückgegebene Segment angibt.

Anfrage

GET /file.bin HTTP/1.1
Host: example.com
Range: bytes=0-511

Antwort

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-511/8192
Content-Length: 512

CORS

GET ist eine von CORS auf die Safelist gesetzte Methode. Ursprungsübergreifende GET-Anfragen lösen keine Preflight-Anfrage aus, wodurch GET im Browser die Standardmethode für das ursprungsübergreifende Abrufen von Ressourcen ist.

GET im Vergleich zu POST

GET ruft Daten ab. POST übermittelt Daten zur Verarbeitung. GET-Parameter werden im Query-String der URL übertragen, POST-Parameter hingegen im Anfrage-Body.

GET-Antworten sind zwischenspeicherbar und können als Lesezeichen gespeichert werden. POST-Antworten sind nur mit expliziten Frische-Informationen zwischenspeicherbar. URLs unterliegen praktischen Längenbeschränkungen, was die Datenmenge begrenzt, die GET transportieren kann. POST hat keine praktische Begrenzung der Body-Größe.

GET ist sowohl sicher als auch idempotent. POST ist weder das eine noch das andere. Ein wiederholtes GET liefert dasselbe Ergebnis. Ein wiederholtes POST erzeugt doppelte Ressourcen oder löst die Verarbeitung zweimal aus.

Der Performance-Unterschied zwischen GET und POST ist vernachlässigbar. Die Wahl hängt von der Operation ab: Abrufen verwendet GET, Übermitteln verwendet POST.

Sicherheit

GET-Parameter sind in der URL, im Browserverlauf, in Serverprotokollen und in Referer-Headern sichtbar. Sensible Daten wie Passwörter, Tokens und personenbezogene Informationen dürfen niemals in Query-Strings auftauchen.

GET-Anfragen sind CSRF-Angriffen stärker ausgesetzt, da - und -Tags automatisch GET-Anfragen auslösen. POST ist ohne geeignete Tokens ebenfalls anfällig für CSRF.

Weder GET noch POST bietet für sich genommen Verschlüsselung. Zum Schutz der Daten während der Übertragung ist HTTPS erforderlich.

SEO-Auswirkung

Suchmaschinen crawlen mit GET. Googlebot und andere Crawler rufen Seiten über GET ab und indexieren sie, sodass eine Ressource nur dann auffindbar ist, wenn sie auf ein einfaches GET antwortet. Zwischenspeicherbare, idempotente GET-Antworten lassen sich am effizientesten crawlen, da Crawler Validatoren wie ETag und Last-Modified wiederverwenden, um das erneute Abrufen unveränderter Seiten zu überspringen.