Route-Parameter und Constraints
Route-Parameter und Constraints
~13 Min. Lesezeit Zuletzt aktualisiert am 8. August 2026
Um ein EINZELNES Projekt anzuzeigen, brauchen wir dynamische Teile in der URL – Route-Parameter. Dieses Kapitel behandelt sie systematisch, inklusive der Reihenfolge-Falle aus Kapitel 7.
Einfache Route-Parameter
#[Route('/projects/{id}', name: 'project_show', methods: ['GET'])]
public function show(int $id): Response
{
return new Response(sprintf('Projekt-Details für ID %d', $id));
}{id} im Pfad UND int $id als Parameter der Methode – Symfony gleicht den Namen des Platzhalters mit dem Namen des Methoden-Parameters ab und übergibt den Wert automatisch. Der PHP-Typ (int) wird dabei automatisch aus dem String-Wert der URL konvertiert.
Requirements: Route-Parameter einschränken
Ohne Einschränkung würde {id} JEDEN String matchen – auch /projects/abc, was zu einem Fehler führt, sobald PHP versucht, 'abc' zu int zu konvertieren. Mit requirements lässt sich das VOR dem Erreichen des Controllers einschränken:
#[Route('/projects/{id}', name: 'project_show', requirements: ['id' => '\d+'], methods: ['GET'])]
public function show(int $id): Response
{
// ...
}'\d+' ist ein regulärer Ausdruck: nur eine oder mehrere Ziffern. /projects/abc matcht diese Route jetzt NICHT mehr – Symfony sucht stattdessen nach einer ANDEREN passenden Route, oder liefert 404, falls keine existiert.
Die Reihenfolge-Falle aus Kapitel 7, jetzt gelöst
// RICHTIGE Reihenfolge: die spezifischere Route zuerst
#[Route('/projects/new', name: 'project_new', methods: ['GET', 'POST'])]
public function new(): Response { /* ... */ }
#[Route('/projects/{id}', name: 'project_show', requirements: ['id' => '\d+'], methods: ['GET'])]
public function show(int $id): Response { /* ... */ }Mit requirements: ['id' => '\d+'] wäre die Reihenfolge hier TATSÄCHLICH egal geworden, da /projects/new gar nicht erst zum Zahlen-Muster passt – ein zusätzlicher Sicherheitsnetz-Effekt der Requirements, unabhängig von der Deklarationsreihenfolge.
Optionale Parameter mit Default-Werten
#[Route('/projects/{id}/tasks/{status}', name: 'project_tasks', requirements: ['id' => '\d+'])]
public function tasks(int $id, string $status = 'alle'): Response
{
return new Response(sprintf('Aufgaben von Projekt %d, Status: %s', $id, $status));
}Ein Default-Wert im Methoden-Parameter (string $status = 'alle') macht diesen Teil der URL implizit optional – /projects/1/tasks/ UND /projects/1/tasks/offen matchen beide dieselbe Route.
Mehrere HTTP-Methoden auf derselben Route
Für Formulare (Block 3) wird eine Route oft für ZWEI Zwecke gebraucht: das Formular ANZEIGEN (GET) und es NACH dem Absenden VERARBEITEN (POST) – beide auf DERSELBEN Route:
#[Route('/projects/new', name: 'project_new', methods: ['GET', 'POST'])]
public function new(Request $request): Response
{
if ($request->isMethod('POST')) {
// Formular verarbeiten (Kapitel 15)
}
// Formular anzeigen (Kapitel 15)
return new Response('Neues Projekt anlegen');
}Tipp: debug:router aus Kapitel 7 zeigt bei mehreren HTTP-Methoden pro Route diese kommagetrennt an – ein guter Weg, um zu prüfen, ob eine Route WIRKLICH für beide Methoden registriert wurde.