GET

Die GET-Methode fordert die Übertragung einer aktuell ausgewählten Darstellung für die Zielressource an. GET ist der primäre Mechanismus zum Abrufen von Informationen und der Schwerpunkt fast aller Leistungsoptimierungen. Wenn man also von der Abfrage identifizierbarer Informationen über HTTP spricht, meint man in der Regel eine GET-Anfrage.

Es ist verlockend, sich Ressourcenbezeichner als entfernte Dateisystem-Pfadnamen und Darstellungen als Kopie des Inhalts solcher Dateien vorzustellen. In der Tat sind viele Ressourcen auf diese Weise implementiert (siehe Abschnitt 9.1 für entsprechende Sicherheitsüberlegungen). In der Praxis gibt es jedoch keine derartigen Beschränkungen. Die HTTP-Schnittstelle für eine Ressource kann genauso gut als Baum von Inhaltsobjekten, als programmatische Sicht auf verschiedene Datenbankeinträge oder als Gateway zu anderen Informationssystemen implementiert sein. Selbst wenn der URI-Zuordnungsmechanismus an ein Dateisystem gebunden ist, könnte ein Ursprungsserver so konfiguriert sein, dass er die Dateien mit der Anfrage als Eingabe ausführt und die Ausgabe als Darstellung sendet, anstatt die Dateien direkt zu übertragen. Unabhängig davon muss nur der Ursprungsserver wissen, wie jeder seiner Ressourcenkennungen einer Implementierung entspricht und wie jede Implementierung es schafft, eine aktuelle Darstellung der Zielressource in einer Antwort auf GET auszuwählen und zu senden.

Ein Client kann die Semantik von GET so ändern, dass es eine "Bereichsanforderung" ist, die die Übertragung nur eines Teils oder einiger Teile der ausgewählten Darstellung anfordert, indem er ein Range-Header-Feld in der Anforderung sendet ([RFC7233]).

Eine Nutzlast innerhalb einer GET-Anforderungsnachricht hat keine definierte Semantik; das Senden eines Nutzlastkörpers bei einer GET-Anforderung könnte dazu führen, dass einige bestehende Implementierungen die Anforderung zurückweisen.

Die Antwort auf eine GET-Anforderung ist cachefähig; ein Cache darf sie verwenden, um nachfolgende GET- und HEAD-Anforderungen zu erfüllen, sofern das Cache-Control-Headerfeld nichts anderes angibt (Abschnitt 5.2 von [RFC7234]).

Die GET-Methode des HTTP-Protokolls ist vergleichbar mit einem digitalen Bibliothekar. Sie bittet den Server höflich, Daten zu präsentieren, ohne selbst Veränderungen an den Daten vorzunehmen – eine rein passive Anfrage.

Was macht die GET-Methode besonders?

1. Konsistenz: Stellen Sie sich vor, Sie bitten den Bibliothekar mehrmals nach dem gleichen Buch – Sie würden jedes Mal das gleiche Buch bekommen. Ebenso verhält es sich mit der GET-Anfrage: sie liefert konstant das gleiche Ergebnis.
2. Lesen, nicht schreiben: Die GET-Anfrage hat den Charakter eines Beobachters. Sie schaut sich Daten an, verändert sie aber nicht.
3. Informationen in der URL: Stellen Sie sich die URL als Adresse oder Indexkarte vor. Sie gibt an, welches Buch oder welche Information Sie suchen. Aber Vorsicht: Diese Karten sollten keine privaten Notizen enthalten, da sie von anderen eingesehen werden können.
4. Schnelle und effiziente Antworten: Dank der Fähigkeit, Antworten zu speichern (Cache), kann die GET-Methode schnell auf wiederholte Anfragen reagieren, ähnlich wie ein gut organisierter Bibliothekar, der genau weiß, wo jedes Buch steht.

Aber es gibt auch Grenzen:

1. Begrenzter Platz für Notizen: Die URL hat nur begrenzt Platz für Informationen. Es ist, als würden Sie auf einer kleinen Karteikarte schreiben.
2. Keine Geheimnisse: Da URLs sichtbar sind und gespeichert werden können, sollte man keine sensiblen Informationen darauf vermerken.
3. Kein Eingreifen: Ein Beobachter beeinflusst nicht das, was er beobachtet. Daher sollte die GET-Methode nicht verwendet werden, um Daten zu verändern. Dafür gibt es andere Werkzeuge in unserem digitalen Werkzeugkasten.

Insgesamt ist die GET-Methode ein verlässliches und wesentliches Instrument im digitalen Raum, das uns hilft, Informationen effizient und sicher abzurufen.