Endpoints-Tool-Window fuer Symfony- und Laravel-Routen entdecken

1. Das Problem manueller Routen-Suche in gewachsenen Projekten

In einem klassischen Symfony-Projekt sind Routen ueber PHP-Attribute direkt an Controller-Methoden annotiert, in aelteren Projekten dagegen zentral in routes.yaml oder ueber mehrere importierte YAML-Dateien verteilt. Laravel wiederum definiert Routen fluent in routes/web.php und routes/api.php, oft mit Gruppen, Middleware-Zuweisungen und Ressourcen-Routen, die mehrere HTTP-Methoden auf einmal auf einen Controller abbilden. In beiden Faellen ist der Zusammenhang zwischen einer URL und der tatsaechlich ausgefuehrten Methode im Code nicht immer auf den ersten Blick erkennbar.

Ohne Werkzeugunterstuetzung bleibt nur die Volltextsuche nach einem URL-Fragment oder das schrittweise Zurueckverfolgen von Route-Namen durch mehrere Dateien. Bei einer Ressourcen-Route wie Route::apiResource('tasks', TaskController::class) in Laravel ist zudem gar nicht auf den ersten Blick ersichtlich, welche der sieben automatisch erzeugten Routen zu welcher Controller-Methode fuehrt, ohne die Laravel-Konventionen im Kopf zu haben oder sie nachzuschlagen.

2. Das Endpoints-Tool-Window oeffnen und die Grundansicht verstehen

Das Endpoints-Tool-Window erreicht man ueber View > Tool Windows > Endpoints oder ueber Find Action mit dem Suchbegriff 'Endpoints'. PhpStorm scannt dabei automatisch das Projekt nach erkennbaren Routendefinitionen, sowohl aus Symfony-Attributen und -YAML als auch aus Laravel-Routendateien, und listet sie in einer zentralen Tabelle auf, unabhaengig davon, in welcher Datei sie tatsaechlich deklariert sind.

Die Tabelle zeigt pro Zeile die HTTP-Methode, den URL-Pfad, den Routennamen und die zustaendige Controller-Methode. Ein Doppelklick auf eine Zeile springt direkt zur Definition, bei Symfony-Attributen zur annotierten Methode, bei Laravel-Routen wahlweise zur Zeile in der Routendatei oder direkt zur Controller-Methode, je nachdem, welche Spalte angeklickt wird.

#[Route('/api/aufgaben/{id}', name: 'aufgabe_show', methods: ['GET'])]
public function show(int $id): JsonResponse
{
    $aufgabe = $this->aufgabenRepository->find($id);

    return $this->json($aufgabe);
}

3. Symfony-Routen ueber Attribute erkennen und navigieren

Bei modernen Symfony-Projekten, die Routen ausschliesslich ueber #[Route]-Attribute direkt an den Controller-Methoden definieren, liest das Endpoints-Tool-Window diese Attribute aus und listet sie zusammen mit allen dort angegebenen Optionen auf, etwa dem Routennamen, den erlaubten HTTP-Methoden und eventuellen Anforderungen an Platzhalter ueber requirements. Aendert sich der Pfad im Attribut, aktualisiert sich der Eintrag im Tool-Window automatisch beim naechsten Scan.

Besonders nuetzlich ist das bei Controllern mit vielen thematisch verwandten Endpunkten, etwa einem AufgabenController mit separaten Methoden fuer Liste, Detailansicht, Erstellen, Aktualisieren und Loeschen. Statt die Klasse von oben nach unten zu durchscrollen, zeigt das Endpoints-Fenster alle fuenf Routen auf einen Blick, gefiltert und sortierbar nach HTTP-Methode oder Pfad, was besonders bei der Fehlersuche zu einer bestimmten fehlerhaften Anfrage Zeit spart.

4. Zentrale YAML-Routendefinitionen in aelteren Symfony-Projekten

In Projekten, die noch mit zentralen config/routes.yaml-Dateien arbeiten oder Routen ueber mehrere importierte YAML-Dateien pro Bundle organisieren, erkennt das Endpoints-Tool-Window auch diese Definitionen und loest den controller-Schluessel korrekt zur tatsaechlichen PHP-Methode auf. Das ist besonders wertvoll, weil die Zuordnung von YAML zu PHP-Klasse rein textuell, also ohne IDE-Unterstuetzung, fehleranfaellig und muehsam ist.

Bei gemischten Projekten, in denen manche Bundles Attribute und andere noch YAML nutzen, listet das Tool-Window beide Quellen einheitlich in derselben Tabelle auf. Das erleichtert eine schrittweise Migration von YAML zu Attributen erheblich, weil sich der Fortschritt direkt am Tool-Window ablesen laesst, ohne dass man wissen muss, in welcher Datei eine bestimmte Route aktuell noch definiert ist.

aufgabe_show:
    path: /api/aufgaben/{id}
    controller: App\Controller\AufgabenController::show
    methods: [GET]
    requirements:
        id: '\d+'

5. Laravel-Routen inklusive Ressourcen-Routen entdecken

Bei Laravel-Projekten scannt das Endpoints-Tool-Window routes/web.php und routes/api.php sowie zusaetzliche, ueber require oder Route::group importierte Dateien. Einfache Route::get- oder Route::post-Definitionen erscheinen direkt mit Pfad, Methode und referenzierter Controller-Methode als eigene Zeile in der Tabelle.

Der eigentliche Mehrwert zeigt sich bei Route::apiResource() oder Route::resource(): PhpStorm kennt die Laravel-Konvention, dass eine solche Zeile automatisch sieben Routen mit den Standardmethoden index, show, store, update und destroy erzeugt, und listet jede dieser automatisch generierten Routen einzeln auf, mit korrektem HTTP-Verb und der zugehoerigen Methode im referenzierten Controller. Ohne dieses Tool muesste man diese Zuordnung aus dem Gedaechtnis oder der Laravel-Dokumentation rekonstruieren.

Route::apiResource('aufgaben', AufgabenController::class);

// Erzeugt automatisch:
// GET    /aufgaben          -> index
// POST   /aufgaben          -> store
// GET    /aufgaben/{id}     -> show
// PUT    /aufgaben/{id}     -> update
// DELETE /aufgaben/{id}     -> destroy

6. Middleware und Routen-Gruppen im Tool-Window nachvollziehen

Laravel-Routen werden haeufig in Gruppen mit gemeinsamer Middleware definiert, etwa Route::middleware('auth:sanctum')->group(function () { ... }). Das Endpoints-Tool-Window loest solche Gruppierungen auf und zeigt fuer jede einzelne Route innerhalb der Gruppe die vollstaendig zusammengesetzte Middleware-Kette an, ohne dass man die Verschachtelung der Gruppendefinitionen manuell nachvollziehen muss.

Das ist besonders bei der Fehlersuche wertvoll, wenn eine Anfrage unerwartet mit 401 oder 403 fehlschlaegt: Statt durch mehrere verschachtelte Route::group-Bloecke zu scrollen, zeigt ein Blick auf die entsprechende Zeile im Endpoints-Fenster sofort, welche Middleware-Kette tatsaechlich fuer diese konkrete Route aktiv ist, einschliesslich vererbter Middleware aus umschliessenden Gruppen.

7. Routen filtern und gezielt suchen

Bei Projekten mit mehreren hundert Routen ist das Filterfeld am oberen Rand des Tool-Windows der schnellste Weg zum Ziel. Eine Eingabe wie 'aufgaben' filtert sofort auf alle Routen, deren Pfad, Name oder Controller diesen Begriff enthaelt, unabhaengig davon, ob die Route ueber ein Symfony-Attribut oder eine Laravel-Ressourcen-Route entstanden ist.

Zusaetzlich laesst sich die Tabelle nach HTTP-Methode gruppieren oder sortieren, was bei der Suche nach allen destruktiven Endpunkten, also DELETE- und teils PUT-Routen, hilfreich ist, etwa im Rahmen einer Sicherheitsueberpruefung, bei der gezielt kontrolliert werden soll, welche Routen tatsaechlich Schreibzugriff ermoeglichen und ob sie durchgaengig mit passender Middleware oder passenden Symfony-Security-Voter-Checks abgesichert sind.

8. Von der Controller-Methode zurueck zur Route navigieren

Die Navigation funktioniert auch in umgekehrter Richtung: Steht der Cursor in einer Controller-Methode, zeigt PhpStorm ueber ein Gutter-Icon am linken Rand der Zeile an, dass diese Methode einer Route zugeordnet ist. Ein Klick auf dieses Icon oeffnet ein Popup mit den zugehoerigen Routendefinitionen und erlaubt den direkten Sprung zur YAML- oder PHP-Deklaration.

Diese Reverse-Navigation ist beim Refactoring besonders wertvoll: Bevor eine Controller-Methode umbenannt oder in eine andere Klasse verschoben wird, zeigt das Gutter-Icon sofort, ob und welche Route betroffen ist, sodass die Route-Referenz gezielt mitgepflegt werden kann, statt sie erst nach einem fehlgeschlagenen Deploy als 404 zu entdecken.

9. Praktischer Nutzen fuer Einarbeitung und API-Dokumentation

Fuer neue Teammitglieder, die sich in ein bestehendes Symfony- oder Laravel-API-Projekt einarbeiten, ist das Endpoints-Tool-Window oft der schnellste Weg zu einem Gesamtueberblick ueber die verfuegbaren Endpunkte, deutlich schneller als das Durchlesen einer moeglicherweise veralteten externen API-Dokumentation. Die Liste im Tool-Window ist immer aktuell, weil sie direkt aus dem Code generiert wird, nicht aus einer separat gepflegten Dokumentationsdatei.

In der Praxis lohnt es sich, bei einer Code-Review-Sitzung fuer eine neue Feature-Branch das Endpoints-Fenster kurz zu oeffnen und auf neu hinzugekommene Routen zu pruefen. Das macht sichtbar, ob versehentlich ein Debug-Endpunkt ohne Middleware-Absicherung im Code verblieben ist, bevor er in den Live-Betrieb gelangt, ein Fehler, der in reinem Textdiff der Routendatei leicht uebersehen wird. Gerade bei API-Projekten, die von mehreren Teams parallel weiterentwickelt werden, ersetzt diese Praxis in vielen Faellen eine separat gepflegte OpenAPI-Uebersicht, die ohnehin staendig aktuell gehalten werden muesste, waehrend das Tool-Window diese Aktualitaet automatisch aus dem Code selbst bezieht.

10. Zusammenfassung

11. FAQ: Endpoints-Tool-Window: Das Wichtigste auf einen Blick