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?
Antworten
Zu viele Anzeigen?Wenn Sie eine GET-Anfrage verwenden, um den Backend-Status zu ändern, besteht die Gefahr, dass schlechte Dinge passieren, wenn ein Webcrawler irgendeiner Art Ihre Website durchläuft. Als Wikis erstmals populär wurden, gab es Horrorgeschichten von ganzen Websites, die gelöscht wurden, weil die "Seite löschen" Funktion als GET-Anfrage implementiert wurde, mit katastrophalen Folgen, als der Googlebot klopfte...
"Verwenden Sie GET, wenn: Die Interaktion eher wie eine Frage ist (d.h. es handelt sich um eine sichere Operation wie eine Abfrage, eine Leseoperation oder eine Suche)."
"Verwenden Sie POST, wenn: Die Interaktion eher wie eine Bestellung ist oder die Interaktion den Zustand der Ressource auf eine Weise ändert, die der Benutzer wahrnehmen würde (z.B. eine Anmeldung für einen Dienst), oder der Benutzer für die Ergebnisse der Interaktion verantwortlich gemacht werden könnte."
Nach den HTTP-Spezifikationen ist GET sicher und idempotent, während POST weder sicher noch idempotent ist. Das bedeutet, dass eine GET-Anfrage mehrmals wiederholt werden kann, ohne Nebenwirkungen zu verursachen.
Selbst wenn Ihr Server sich nicht darum kümmert (was unwahrscheinlich ist), können zwischen Ihrem Client und dem Server Zwischeninstanzen vorhanden sein, die alle diese Erwartung haben. Beispielsweise Proxies, die Daten bei Ihrem Internetdienstanbieter oder anderen Anbietern zwischenspeichern, um die Leistung zu verbessern. Die gleiche Erwartung gilt auch für Beschleuniger, zum Beispiel ein Prefetching-Plugin für Ihren Browser.
Daher kann eine GET-Anfrage zwischengespeichert werden (basierend auf bestimmten Parametern) und bei einem Fehler automatisch wiederholt werden, ohne schädliche Auswirkungen zu haben. Ihr Server sollte also wirklich versuchen, diesen Vertrag zu erfüllen.
Andererseits ist POST nicht sicher, nicht idempotent und jeder Agent weiß, dass die Ergebnisse einer POST-Anfrage nicht zwischengespeichert werden oder eine POST-Anfrage automatisch wiederholt wird. Zum Beispiel würde eine Kreditkartentransaktion niemals eine GET-Anfrage sein (Sie möchten nicht, dass Konten aufgrund von Netzwerkfehlern mehrmals belastet werden).
Das ist ein sehr grundlegendes Verständnis. Für weitere Informationen könnte das Buch "RESTful Web Services" von Ruby und Richardson (O'Reilly-Presse) in Betracht gezogen werden.
Für eine schnelle Einführung in das Thema REST empfehle ich diesen Beitrag:
http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx
Das Lustige ist, dass die meisten Leute die Vorzüge von PUT gegenüber POST diskutieren. Die Frage GET gegen POST ist jedoch bereits sehr gut geklärt. Ignorieren Sie sie auf eigene Gefahr.
GET hat Einschränkungen auf der Browserseite. Zum Beispiel legen einige Browser die Länge von GET-Anfragen fest.