Wenn man die Wahl hat, einen Partial Refresh via HTTP GET oder via HTTP POST auszulösen, sollte aus Gründen der Performance stets die GET-Variante bevorzugt werden. Das läßt sich durch zwei Umstände begründen:
1. Handling des XMLHttpRequests im Browser
Wird ein XMLHttpRequest mittels POST abgeschickt, geschieht dies in zwei Schritten: Erst wird der Header gesendet, daraufhin im zweiten Schritt die Daten; es werden also mindestens zwei TCP-Pakete verschickt. Da die Daten bei GET-Requests auf eine maximale URL-Länge von 2K begrenzt sind, daher passen sie meistens in ein TCP-Paket, was die Kommunikation beschleunigt und den Server entlastet. Ausnahme hierbei: Man hat zuviele Cookies, denn diese werden im Request mitübertragen und vergrößern so die Datenmenge.
2. Handling des Requests im JSF-Lifecycle
Bei einem GET Request werden nur zwei Phasen des JSF-Lifecycles ausgeführt: Die „Restore View„-Phase und die „Render Response„-Phase. Das beschleunigt die Serverseitige Bearbeitung um ein vielfaches. POST Requests durchlaufen den kompletten JSF-Lifecycle.
Fazit
Solange die Datenmenge also gering bleibt bzw. sich die Absicht des Partial Refreshs nur auf den Abruf von Daten bzw. das Ausführen von SSJS beschränkt (z.B. beim Updaten eines Seitenbereiches, o.ä.), gewinnt ein XSP.partialRefreshGet immer vor einem XSP.partialRefreshPost. Dies sollte konsequent bei der Entwicklung berücksichtigt werden. Denn meistens ist die Notwendigkeit, einen Partial Refresh mittels POST durchzuführen, nicht wirklich gegeben.
Übrigens:
Ein GET Request encodiert die zu übertragenen Daten in die URL des Requests. Überschreitet die Datenmenge die maximale Länge einer URL, führt das unweigerlich zu Fehlern auf dem Server.
