GET vs. POST spielt es wirklich eine große Rolle?

Question

Ok, ich kenne den Unterschied im Zweck. GET ist dazu da, um Daten abzurufen. Eine Anfrage stellen und Daten erhalten. POST sollte für CRUD-Operationen verwendet werden, die nicht das Lesen betreffen, glaube ich. Aber letztendlich, kümmert es den Server wirklich, ob er am Ende ein GET gegen ein POST erhält?

Answer 1

Entsprechend dem HTTP RFC sollte GET keine Nebenwirkungen haben, während POST Nebenwirkungen haben kann.

Das grundlegendste Beispiel hierfür ist, dass GET nicht geeignet ist für etwas wie einen Kaufvorgang oder das Veröffentlichen eines Artikels in einem Blog, während POST für Handlungen geeignet ist, die Konsequenzen haben.

Laut RFC kann ein Benutzer für Handlungen, die durch POST durchgeführt werden (wie ein Kauf), verantwortlich gemacht werden, aber nicht für GET-Handlungen. 'Bots verwenden aus diesem Grund immer GET.

Aus dem RFC 2616, 9.1.1:

9.1.1 Sichere Methoden

Implementierer sollten sich dessen bewusst sein, dass die Software den Benutzer in
ihren Interaktionen über das Internet darstellt, und sollten darauf achten, dem Benutzer zu ermöglichen, sich der möglichen Auswirkungen ihrer Handlungen bewusst zu sein
anderen oder sich selbst.

Insbesondere hat sich die Konvention etabliert, dass die GET- und
HEAD-Methoden NICHT die Bedeutung haben sollten, eine Handlung
außer der Abfrage durchzuführen. Diese Methoden sollten als "sicher" angesehen werden. Dies ermöglicht es Benutzer-Agenten, andere Methoden wie POST, PUT und
DELETE auf besondere Weise darzustellen, so dass dem Benutzer bewusst wird, dass eine möglicherweise unsichere Aktion angefordert wird.

Natürlich ist es nicht möglich sicherzustellen, dass der Server keine Nebenwirkungen erzeugt, wenn ein GET-Anfrage ausgeführt wird; tatsächlich erwägen einige dynamische Ressourcen dies als
Merkmal. Der wichtige Unterschied besteht darin, dass der Benutzer nicht um die Nebenwirkungen gebeten hat,
und kann deshalb nicht dafür verantwortlich gemacht werden.

Answer 2

Es geschieht, wenn eine Suchmaschine die Seite durchsucht, da sie GET-Anfragen stellen wird, aber nicht POST. Angenommen, Sie haben einen Link auf Ihrer Seite:

http://www.example.com/items.aspx?id=5&mode=delete

Ohne eine Art Autorisierungsprüfung, die vor dem Löschen durchgeführt wird, ist es möglich, dass Googlebot möglicherweise hereinkommt und Elemente löscht von Ihrer Seite.

Answer 3

Da Sie höchstwahrscheinlich die Serversoftware schreiben, interessiert es diese, wenn Sie ihr sagen, dass es wichtig ist. Wenn Sie POST- und GET-Daten identisch behandeln, dann nicht.

Der Browser dagegen kümmert sich definitiv darum. Wenn Sie eine Seite neu laden oder zurückklicken, um zu einer Seite zu gelangen, die Sie als Antwort auf einen POST erhalten haben, erscheint beispielsweise die Meldung "Sind Sie sicher, dass Sie die Daten erneut senden möchten?".

Answer 4

GET hat Datenlimitbeschränkungen basierend auf dem sendenden Browser:

Die Spezifikation für die URL-Länge legt keine Mindest- oder Höchstlänge fest, aber die Implementierung variiert je nach Browser. Unter Windows: Opera unterstützt ~4050 Zeichen, IE 4.0+ unterstützt genau 2083 Zeichen, Netscape 3 -> 4.78 unterstützt bis zu 8192 Zeichen, bevor es zu Fehlern beim Herunterfahren kommt, und Netscape 6 unterstützt ~2000 Zeichen, bevor es zu Fehlern beim Start kommt

Answer 5

Du bist dir einiger subtiler Sicherheitsunterschiede bewusst. Siehe meine Frage

GET versus POST hinsichtlich Sicherheit?

Im Wesentlichen ist das Wichtige zu beachten, dass GET in den Browserverlauf gelangt und im Klartext durch Proxies übertragen wird, daher möchten Sie keine sensiblen Informationen wie ein Passwort in einem GET haben.

Offensichtlich vielleicht, aber erwähnenswert.