Was ist der Unterschied zwischen get und post?

[RichardWotzlaw]

Hallo,

das Thema raubt die Spannung.
Ich verstehe beim besten Willen nicht, wo zwischen method=post und method=get der Unterschied sein soll oder wozu es überhaupt einen gibt!
Danke für die Erklärungen!

Gruß aus MeckPomm

[afra]

Hallo RichardWotzlaw!

Ich verstehe beim besten Willen nicht, wo zwischen method=post und method=get der Unterschied sein soll oder wozu es überhaupt einen gibt!
Danke für die Erklärungen!

Eine Archivsuche hätte Dir helfen können den Verstand zu behalten...

Schönen Gruß

Afra

[Der Martin]

Hallo Richard,

Ich verstehe beim besten Willen nicht, wo zwischen method=post und method=get der Unterschied sein soll oder wozu es überhaupt einen gibt!

Technisch betrachtet:
Bei GET werden zusätzliche Parameter (z.B. Formulardaten) in der URL übertragen, also mit dem bekannten Schwänzchen ?param1=wert1&param2=wert2&...
Bei POST werden die gleichen Daten im Request-Body übertragen.

Vor- und Nachteile:
1. Bei GET sieht der User, welche Daten übergeben werden (kann man als Vorteil oder als Nachteil sehen)
2. Bei GET ist die Länge begrenzt, bei POST nicht
3. Die Ergebnisseite eines GET-Formulars kann man bookmarken, da alle nötigen Informationen in der URL enthalten sind
4. Die Ergebnisseite eines POST-Formulars kann man weder bookmarken noch im Browser aktualisieren, da die Daten nicht mehr zur Verfügung stehen
5. File-Upload ist nur mit POST möglich

Aus Punkt 4. folgt außerdem, dass man ein Formular mit method="post" nicht aus Versehen mehrmals abschicken kann (z.B. indem man nach dem Abschicken die "Zurück"-Funktion des Browsers verwendet und dann erneut abschickt). Deswegen wird empfohlen, POST für Formulare zu verwenden, die irgendeine nachhaltige Veränderung auf der Serverseite bewirken - z.B. ein Eintrag in eine Datenbank, das Versenden einer Nachricht etc., während GET für solche Zwecke eingesetzt werden sollte, bei denen ein Mehrfachaufruf keine unerwünschten Nebeneffekte hat - also etwas eine reine Datenbankabfrage, eine Suchanfrage, etc.

Ich hoffe, damit kannst du ein bisschen was anfangen.

Schönes Wochenende noch,
 Martin

[Christian Seiler]

Hallo Martin,

Aus Punkt 4. folgt außerdem, dass man ein Formular mit method="post" nicht aus Versehen mehrmals abschicken kann (z.B. indem man nach dem Abschicken die "Zurück"-Funktion des Browsers verwendet und dann erneut abschickt).

Naja, Du kannst das POST-Formular durchaus über die History nochmal aus Versehen abschicken lassen (alle mir bekannten Browser behalten die Daten zwischengespeichert), allerdings fragen alle mir bekannten Browser auch nach, ob man das wirklich tun will.

Viele Grüße,
Christian

[Der Martin]

Hallo Christian,

Naja, Du kannst das POST-Formular durchaus über die History nochmal aus Versehen abschicken lassen

das stimmt natürlich, da hab ich mich ungenau ausgedrückt.

allerdings fragen alle mir bekannten Browser auch nach, ob man das wirklich tun will.

Eben, und da sollte man stutzig werden, so dass das "aus Versehen" doch nahezu ausgeschlossen ist.

Schönen Tag noch,
 Martin

[Christian Seiler]

Hallo Martin,

allerdings fragen alle mir bekannten Browser auch nach, ob man das wirklich tun will.

Eben, und da sollte man stutzig werden, so dass das "aus Versehen" doch nahezu ausgeschlossen ist.

Wenn Du wüßtest, wie oft ich bei dieser Meldung schon einfach "Enter" gedrückt habe, ohne darüber nachzudenken...

Viele Grüße,
Christian

[Tim Tepaße]

Hallo Martin,

Bei GET werden zusätzliche Parameter (z.B. Formulardaten) in der URL übertragen, also mit dem bekannten Schwänzchen ?param1=wert1&param2=wert2&.. Bei POST werden die gleichen Daten im Request-Body übertragen.

Streng genommen sollte man wohl noch sagen, dass die Daten im Body von POST beliebig strrukturiert (XML..) sein können, anstatt in key=value eingesperrt zu sein. Ja, ich weiss, man kann natürlich alles von einem ins andere umkodieren, aber will man das?

... während GET für solche Zwecke eingesetzt werden sollte, bei denen ein Mehrfachaufruf keine unerwünschten Nebeneffekte hat - also etwas eine reine Datenbankabfrage, eine Suchanfrage, etc.

Ich mag die semantische Interpretation des Unterschiedes lieber. Insbesondere, wenn auch noch PUT und DELETE mit ins Spiel kommen.

Tim

[Der Martin]

Hallo Tim,

Streng genommen sollte man wohl noch sagen, dass die Daten im Body von POST beliebig strrukturiert (XML..) sein können, anstatt in key=value eingesperrt zu sein.

das ist natürlich korrekt - das Format und der Inhalt der übertragenen Daten ist von der jeweiligen Anwendung abhängig. Das gilt aber für GET auch, denn http://example.org?EndlichWochenende ist ja auch eine gültige URL. Wichtig ist die serverseitige Logik, die den Request verarbeitet; wenn die ein anderes Schema als die üblichen key=value-Pärchen interpretiert, ist das okay.

Ich mag die semantische Interpretation des Unterschiedes lieber.

Was meinst du damit? Etwa sowas:
GET wird benutzt, wenn ich mir etwas vom Server HOLE, wofür ich eventuell Auswahlinformationen mitgeben muss.
POST benutzt man, um etwas zum Server zu SCHICKEN, wobei die als Antwort zurückkommende Information zweitrangig ist.

Insbesondere, wenn auch noch PUT und DELETE mit ins Spiel kommen.

Mir ist noch kein Fall untergekommen, wo diese Methoden wirklich verwendet wurden, obwohl ich mir ein paar interessante Anwendungen vorstellen könnte. Mal abgesehen von der fehlenden Unterstützung durch gängige Browser (wozu auch), hat der Apache das eigentlich komplett implementiert?

Schönes Wochenende noch,
 Martin

[Tim Tepaße]

Hallo Martin,

Was meinst du damit? Etwa sowas:
GET wird benutzt, wenn ich mir etwas vom Server HOLE, wofür ich eventuell Auswahlinformationen mitgeben muss. POST benutzt man, um etwas zum Server zu SCHICKEN, wobei die als Antwort zurückkommende Information zweitrangig ist.

Geenau. Im Prinzip ist in HTTP die Semantik der vier wesentlichen Verben¹definiert, also sollte es in einer idealen Welt keine Verständnisprobleme da geben. In der realen Welt wird das dann nicht beachtet und GET hat dann Nebeneffekte auf dem Server. Aber nun ja. Wobei festzustellen ist, dass das grundsätzliche HTTP Prinzip  derzeit als Representational State Transfer (REST) wieder halbwegs gehypt wird, als eine Art objekt-orientierter Web-Service im Gegensatz zu den eher prozeduralen Varianten XML-RPC und teilweise auch SOAP. Und auch unter RESTafarians gibt es Unterscheidungen, ganz neu in Hi-REST und Lo-REST (Nur GET und POST).

¹ Warum diese so wesentlich sind, ist sehr gut in Joe Gregorios Artikel How to create a REST Protocol erklärt.

Insbesondere, wenn auch noch PUT und DELETE mit ins Spiel kommen.
Mir ist noch kein Fall untergekommen, wo diese Methoden wirklich verwendet wurden ...

Man findet das auch eher nur in Protokollen, die auf HTTP aufbauen. Protokollen, die restful sind. Ein paar Beispiele, die mir in letzter Zeit untergekommen sind:

• WebDAV wird durchaus schon ziemlich in der Realität eingesetzt, um Zeug auf Servern zu speichern und zu löschen und zu verschieben ... sehr abgekürzt ist es ein FTP über HTTP.

• Das Atom Publishing Protocoll, mit dem man Weblogs extern editieren kann, z.B. in ecto oder MarsEdit. Auch wenn AAP noch in der Entwicklung ist, findet man es bereits im Einsatz in der freien Wildbahn, z.B. im Google-Service blogger.com.

• Die Amazon Web Services werden auch jeweils in einer REST-Version angeboten, ganz neu z.B. deren Storage-Service Amazon S3. Aber auch bei anderen Größen findet man das, z.B. bei Yahoo.

Mal abgesehen von der fehlenden Unterstützung durch gängige Browser (wozu auch)

Als Interface wird das wahrscheinlich schwierig, da stimmt Dein "Wozu auch". Allerdings ist im Prinzip auch nicht unbedingt unsinnig. In der Quellcode-Anzeige des Mac-Browsers OmniWeb gibt es einen Button „Abspeichern“, mit den man das veränderte Dokument wieder mittels PUT auf dem Server abspeichern kann (Screenshot). Wenn der Server das erlaubt. Ebenso der Experimental-Browser des W3C, Amaya, der übrigens gaaanz laaaangsam besser wird. Beinahe benutzbar. Bei Amaya liegt das übrigens nahe, Amaya ist ja nicht nur ein Browser, sondern auch ein WYSIWYG-Editor, der es folglich erlaubt, Dokumente (Ressourcen) gleich über HTTP zu speichern. Und Amaya unterstützt auch WebDAV, um Ressourcen für andere gleich zu sperren, während man sie direkt in seinem Browser verändert. Aber eine Unterstützung für DELETE habe ich noch in keinem Browser entdeckt.

hat der Apache das eigentlich komplett implementiert?

Als genereller Webserver hat Apache eigentlich keine Probleme mit den unterschiedlichen Verben von HTTP. Nur: Es steht nirgendwo fest, was er damit machen soll. Frisch ausgelieferten Apachen ein DELETE zu erlauben, ist ein ziemliches Risiko. Also wirft er immer ein "Method not allowed". Aber man kann es freischalten. Nur: So wie ich die Apache Dokumentation verstehe, weiss der Apache nicht, dass die Methode PUT einem Schreiben in das Dateisystem entspricht analog dem Lesen bei GET. Merkwürdig bei einem Webserver, der eigentlich nur Ressourcen in Dateien umsetzt. Also lautet wohl die Variante beim Apachen für die Unterstützung von PUT und DELETE auf ein Programm oder Script umzulenken:

Script PUT /~bob/put.cgi

... idealerweise natürlich noch zugangsgeschützt mit <Limit>. Kann aber auch gut sein, dass es dafür inzwischen komfortablerer Lösungen gibt, das letzte Mal als ich mir das näher angeguckt habe, ist schon etwas her. Ich wollte mir ein minimales lokales Wiki als Gedankenstütze hier einrichten, editiert hätte ich das dann mit OmniWeb wie oben erwähnt. Habe ich dann aber wegen wasauchimmer aufgeschoben.

Tim