Formular via GET bzw. POST

[Sympathisant]

Hai allerseits,

ich stehe vor der Entscheidung ein Suchformular entweder mittels GET oder POST abzuschicken.
Meiner Meinung nach spricht fuer GET, dass man die Suchergebnisseite bookmarken kann. Fuer POST spricht, dass die URL nicht kryptisch ausschaut.

Allerdings beinhaltet das Suchformular gut 30 Input-Felder.
Gibt es eine Art Regel, nach der man hier vorgeht?

Im Archiv fand ich folgendes:
• 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.

Aehnliche Aussage
http://forum.de.selfhtml.org/archiv/2009/5/t186467/#m1238511

Bei einer Suche waere also GET angebracht.

Kann man sich daran orientieren?

Besten Dank!

MfG,
Sympatisant

[LX]

Derartige Grundregeln für die Aufteilung von GET/POST-Requests aufzustellen, sind gut, noch besser ist es jedoch, sich Gedanken zu machen, wie man sie am sinnvollsten umsetzt.

Wenn Du die Vorteile eines GET-Requests mit den Vorteilen eines POST-Requests kombinieren willst, generiere die GET-URL per JS bzw. per POST-Redirect als non-JS-Fallback, so dass das Suchformular beispielsweise folgendem URL-Schema entspricht:

http://meineurl.de/suche/[suchbegriff]/[Seitenzahl]/[Optionszusammenfassung]

So ist die URL weniger kryptisch und kann trotzdem gebookmarkt werden. Serverseitig baust Du aus der URL per Rewrite wieder einen normalen GET-String zusammen.

Gruß, LX

[dedlfix]

echo $begrüßung;

http://meineurl.de/suche/[suchbegriff]/[Seitenzahl]/[Optionszusammenfassung]
So ist die URL weniger kryptisch und kann trotzdem gebookmarkt werden. Serverseitig baust Du aus der URL per Rewrite wieder einen normalen GET-String zusammen.

Rewrite ist eine Möglichkeit, vermutlich die bekannteste. Und aus PHP-Script-Sicht [*] auch die bequemste, bekommt man doch alle Werte im $_GET-Array präsentiert. Aber es wird - zumindst bei 30 Feldern - sehr aufwendig, die Umschreibregel zu formulieren. Eine alternative Möglichkeit ist, direkt REQUEST_URI oder PATH_INFO [**] im Script auszuwerten.

PHP angenommen, kann man die URL so gestalten: .../script.php/path/info. Das setzt voraus, dass das Feature PathInfo im Webserver freigegeben ist (oft der Fall) und dass der Scriptname vollständig ist (also meist das .php hintendran braucht).

Mit mod_rewrite kann man auch das script.php aus der URL bekommen. Man schreibe alles, was keine real existierende Datei oder Verzeichnis ist auf das Script um. Im Script müsste (wenn ich mich recht erinnere) die REQUEST_URI auswertbar sein, die die ursprüngliche nicht umgeschriebene URL enthält.

[*] Ob tatsächlich PHP beim OP im Einsatz ist oder was anderes, ist weniger relevant. Das Prinzip gilt (meist) auch für andere Systeme.
[**] oder einen anderen passenden Eintrag in $_SERVER

echo "$verabschiedung $name";

[hotti]

moin,

fürn Suchformular nehme ich auch GET. Kein Problem mit Reload und der Suchvorgang bekommt damit einen URI.

Allerdings beinhaltet das Suchformular gut 30 Input-Felder.

Mein Gott. Das braucht ja ein ausgebildetes Team von Suchmaschinisten ;-)

Hotte

[Sympathisant]

Hai,

OK, danke euch!

Ich habe mich nun fuer GET entschieden.

MfG,
Sympatisant