Tim Tepaße: Get oder Post

Beitrag lesen

Hallo,

Welche Datenübertragung ist besser?
Get oder Post?

Die reine Lehre nach dem HTTP Standard sagt, dass man nur POST (und das unbenutzbare PUT) für Datenübertragung nutzen soll. Dort gibt es den Gedanken von „sicheren Methoden“, d.h. HTTP Methoden, die keine verändernden Nebeneffekte auf Seiten des Servers haben sollen. Diese Methoden sind dann nur dafür da, Informationen abzuholen, nicht um Informationen abzuliefern. Der Vorteil dadurch ist dann, dass man größtenteils nur anhand der Methode bestimmen kann, ob der HTTP Request direkt bis zum Server und der Programmlogik durchgereicht werden soll, oder ob der Request schon vorher durch Proxy, Cache oder Conditional GET beantwortet werden kann. Caching ist dadurch ein HTTP eingebautes Feature.

„Sicher“ heisst es auch, weil dadurch bei schlechten Bots und Prefetching-Massnahmen Requests dann keine störenden Nebeneffekte ausführen. Stell Dir mal eine Webseite vor, in der ein Link zum Löschen von etwas ist:

/foo?deleteEntry=1234

Ein schlechter Bot oder ein Prefetching-Algorithmus im Browser könnte dann versehentlich diesen Link aufrufen und die Löschung vollziehen, obwohl das gar nicht Absicht war. Der Google Web Accelerator litt meines Wissens in den Anfangstagen kurzzeitit unter so einer Kinderkrankheit.

Aber ja, tatsächlich wird diese Unterscheidung seltens beachtet. In letzter Zeit hat sie durch den Webservices-Architekturstil REST wieder etwas Aufmerksamkeit bekommen. Und besonders dumm ist ist auch nicht, deswegen sollte man die von Jeena gegebene Faustregel vielleicht noch dadurch erweitern:

• GET für Parameter, die sich auf die Darstellung der abzuholenden Informationen beziehen, nicht aber den Datenbestand auf Seiten des Servers verändern, erweitern oder gar löschen.

• POST für Request, die den Datenbestand auf dem Server verändern, erweitern oder löschen.

(Und PUT und DELETE nutzt man höchstens in REST-basierten Web-Services und mit Javascript, da die Formulare in HTML unter der dämlichen Einschränkung leiden.)

Tim