Routing is the FIRST step of every Symfony request: an incoming URL gets mapped to a PHP method. Let's now start with the actual structure of our task manager project.

Attribute-based routing: the modern standard

As already briefly seen in chapter 3, Symfony prefers defining routes DIRECTLY above the controller method as a PHP attribute – the route and the code stay visible in ONE place:

<?php

declare(strict_types=1);

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;

class ProjectController extends AbstractController
{
    #[Route('/projects', name: 'project_index', methods: ['GET'])]
    public function index(): Response
    {
        return new Response('Project list (comes in chapter 8)');
    }
}

name: 'project_index' assigns a UNIQUE, internal identifier to this route – EXACTLY this name is what gets used later in Twig templates (chapter 13) and controller redirects (chapter 11), NEVER the raw URL itself. This is one of Symfony's most important principles: URLs can change later, route names stay stable.

methods: ['GET'] restricts the route to HTTP GET – if a client calls the same URL with POST, this route does NOT match (Symfony responds with 405 Method Not Allowed, provided no other route matches).

Listing all routes in the project

php bin/console debug:router

An indispensable tool throughout ALL of development – shows EVERY registered route with its name, method, path, and associated controller. If unsure whether a route registered as expected, this is the first thing to check.

php bin/console debug:router project_index
# shows details for EXACTLY that one route

YAML-based routing: the alternative

Symfony still supports routing via central YAML files – less common in modern code, but good to know, since older projects are often built this way:

project_index:
    path: /projects
    controller: App\Controller\ProjectController::index
    methods: [GET]

Routing priority: order matters

Symfony checks routes in the order they get LOADED – the FIRST matching route wins. With overlapping patterns (e.g. /projects/new vs. /projects/{id}), the MORE SPECIFIC route must come BEFORE the more general one, otherwise /projects/new would be wrongly interpreted as {id} = 'new'. Chapter 9 goes deeper into this with explicit route constraints.

The project structure grows

src/
└── Controller/
    └── ProjectController.php