Aus URLs wie z.B. der folgenden:

http://www.example.com/index.php?action=read&id=2&page=4

wurde also z.B.:

http://www.example.com/read/2/page/4

Die Rewrite-Regeln dafür könnten z.B. so aussehen:

RewriteRule ^read/(\d+?)/page/(\d+?)/?$ index.php?action=read&id=$1&page=$2 [L]
RewriteRule ^read/(\d+?)/?$ index.php?action=read&id=$1 [L]

Diese Regeln verschwinden dann meist in der .htaccess-Datei und es werden nach und nach für jede Action ein oder mehrere Zeilen angelegt. Das Problem dabei ist, dass diese Strategie oft zum .htaccess-Wildwuchs führt, was die Durchsicht (besonders für externe Programmierer) extrem erschwert. Seitenweise Rewrite-Anweisungen sind nicht besonders übersichtlich, insbesondere wenn es darum geht, Sicherheitslücken oder Bugs zu finden.

Viel besser gefällt mir der Ansatz, einfach ALLE relevanten Aufrufe an die index.php (oder eine andere) weiterzuleiten (dem sogenannten Dispatcher), und dann innerhalb der PHP-Applikation zu entscheiden, was zu tun sei. So ist die Logik komplett in einer Programmiersprache vorhanden und nicht in zwei unterschiedlichen Schichten.

Diese meist als Dispatcher bezeichnete Verfahrensweise hat sich für mich in der Vergangenheit mehrfach bewährt. Das setzt natürlich voraus, dass man sich einmal über das URL-Parsing innerhalb von PHP Gedanken gemacht hat. Zu Beginn der Skript-Abarbeitung sollte also die URL in ihre Bestandteile zerlegt werden, und evtl. die Gültigkeit geprüft werden. Wenn das Ganze noch in ein eine kleine Klasse verpackt ist, dann kann jede Folge-Funktion komfortabel auf die ermittelten Werte zurückgreifen (was natürlich auch quick’n'dirty mit einer globalen Variable funktioniert).

Laut Wikipedia ist ein Dispatcher folgendes:

Ein Dispatcher (engl. to dispatch = etwas erledigen, abschicken) ist ein Einsatzleiter, Koordinator, Zuteiler. Wörtlich „Schnell-Erlediger“.

Immer mehr Softwareprojekte verfahren auf diese Weise (z.B. auch Wordpress) und vereinfachen damit die Wartung des Systems erheblich, da nun nicht mehr an mindenstens 2 Stellen gesucht und erweitert werden muss. So ist es auch nicht mehr notwendig, z.B. aufgrund neu angelegter Kategorien die .htaccess-Datei mit neuen Regeln zu bestücken, da die Entscheidung, ob ein Aufruf gültig ist oder nicht, nun sowieso in der Anwendung selbst getroffen wird.

Performance-Nachteile kann ich nicht erkennen, denn auch das Parsing der RewriteRules in der .htaccess benötigt Zeit und dort kann man ebenfalls Einiges zu Lasten der Abarbeitungs-Geschwindigkeit verkehrt machen.

Deine Meinung interessiert mich. Siehst Du begründete Vorteile der Variante, alles einzeln in die .htaccess-Datei zu schreiben? Ich bin gespannt.