ChrisB: Wann GET, wann POST verwenden ...?

Beitrag lesen

Hi,

Bislang wurden die Informationen mit $_POST weiter gegeben. Ein unhübsches Problem ist, das bei einem $_POST und einem Reload der Seite so eine doofe Meldung kommt, die man bestätigen muss. Deshalb habe ich beschlossen, diese Fehlermeldung so zu umgehen, dass ich die Sachen jetzt mit $_GET an das Script weiterleite.

Dieser Weg der Entscheidungsfindung ist reichlich unsinnig.

Grundsaetzlich gilt die Faustregel:

  • GET fuer Requests, die wiederholbar die gleichen Parameter uebergeben sollen, und das unabhaengig davon, welcher Nutzer den Request macht. Also bspw. fuer die Anforderung des Ergebnislistungs einer Suchmaschine wie Google, das ich damit bequem verlinken und fuer andere ebenfalls nutzbar machen kann.

  • POST fuer individuelle, nur den jeweiligen Nutzer betreffende Daten - bspw. meinen Login irgendwo, oder auch den Text, den ich hier gerade verfasse und an den Server POSTen werde - den verfasst naemlich kein anderer ausser mir.

Die Entscheidungsfindung hingegen davon abhaengig zu machen, ob bspw. ein Browser beim Reload ggf. nachfragt, ob man wirklich die gleichen Daten erneut senden will, ist bloedsinnig.
Im Falle des Abrufs eines Suchergebnisses moechte ich das vielleicht wirklich - um zu sehen, ob sich etwas am Ergebnis geaendert hat. Bei Request ueber GET problemlos moeglich, und da fragt mein Browser auch nicht nach, ob ich mir wirklich sicher bin, dass ich das will.
Bei einem Forenposting wie diesem hier, welches ich gleich per POST abschicken werde, wuerde mein Browser normalerweise bei einem anschliessenden Reload nachfragen, ob ich wirklich die gleichen Daten nochmal senden moechte - moechte ich hoechstvermutlich nicht, denn wer will schon meinen gleichen Senf in zwei Postings zum Lesen vorgesetzt bekommen ...

Also treffe die Entscheidung darueber, welche Methode die geeignetere ist, danach, welche "Art" von Daten zu uebermitteln sind - und nicht danach, ob dir irgendwelche Browser-Nachfragen *dir* "doof" erscheinen.

(Wenn du die Meldung vermeiden willst, kannst du bspw. nach dem Empfang des POST-Requests auf eine per GET anzufordernde Ressource weiterleiten lassen - dann kommt beim anschliessenden Reload keine Meldung mehr, weil dann nur der GET-Request erneut ausgefuehrt wird.)

Ein Problem ist, dass $_GET die Daten in der URL anzeigt.

Siehste, da raecht es sich schon, die *falsche* Methode zu benutzen.

Da meine Seiten aber in einem Frame eingebettet sind(darüber gibt's keine Diskussion, ist halt so!), und man die URL von den Frames nicht sieht, ist auch dieses Problem aus der Welt!?

Aua.
Denkst du ueber diese Argumentation selber noch mal nach - oder soll *ich* dir gleich sagen, fuer wie meschugge ich sie halte ...?

Jetzt hab ich jedoch gelesen, dass es bei sowas den Vor- bzw. Nachteil gibt, dass die URL in der History gespeichert wird. Deshalb wollte ich mal fragen, ob Frame-adressen in der History gespeichert werden?

Kommt drauf an - auf den Browser. Moeglicherweise ja, moeglicherweise nein.
Da du $browser aber gar nicht kennst, kannst du darueber keinerlei Aussage treffen. (Genausowenig wie bspw. darueber, ob $browser, den du nicht kennst, ueberhaupt die von dir nicht zur Diskussion gestellten Frames ueberhaupt anzeigen kann/mag/darf ...)

Außerdem hab ich ein dummes Gefühl bei der Sache, die Informationen über die URL zu leiten und nicht "versteckt" in einem $_POST.

Gut, dann scheint ja doch ein gewisses Masz an logischem Denkvermoegen vorhanden zu sein :-)
Mit Hilfe der vorgetragenen argumentativen Untermauerung kommst du dann jetzt sicher zum richtigen Schluss.

MfG ChrisB