Block-2-Zusammenfassung: eine eigene Resource bauen

Block 2 ist ABGESCHLOSSEN. Bevor es in Block 3 mit Serialisierung und Validierung WEITERGEHT, fasst dieses Kapitel ALLES Gelernte zusammen – UND lässt es SELBST anwenden.

Was Block 2 behandelt hat

Kapitel 9: #[ApiResource] erzeugt automatisches CRUD aus einer Doctrine-Entity.
Kapitel 10: alle sechs Standard-Operationen einzeln mit curl getestet.
Kapitel 11: Operations als konkrete PHP-Klassen (Get, Post, ...) verstanden.
Kapitel 12: schreibgeschützte Resources durch Weglassen von Klassen (Tag).
Kapitel 13: eigene uriTemplate-Pfade pro Resource und pro Operation.
Kapitel 14: shortName, description und deprecated für bessere Doku.
Kapitel 15: reproduzierbare Testdaten über Doctrine Fixtures.
Kapitel 16: Statuscodes und Fehlerverhalten bei ungültigen Anfragen.
Kapitel 17: die OpenAPI-Spezifikation exportiert und in Postman importiert.

Projektstand am Ende von Block 2

api/src/ – Stand nach Kapitel 17

api/
└── src/
    ├── Entity/
    │   ├── Project.php      ← #[ApiResource], volles CRUD
    │   └── Tag.php          ← #[ApiResource], NUR lesend
    ├── Repository/
    │   ├── ProjectRepository.php
    │   └── TagRepository.php
    └── DataFixtures/
        └── AppFixtures.php  ← 2 Tags + 1 Project

Selbst anwenden: die Status-Entity

Als ABSCHLUSSÜBUNG dieses Blocks: legen Sie SELBST eine dritte Entity Status an (Felder: label string, color string) – GENAU wie Tag soll sie SCHREIBGESCHÜTZT über die API sein (nur GetCollection und Get), mit eigenen Fixtures (z. B. "Offen", "In Arbeit", "Erledigt").

bin/console make:entity Status ausführen, Felder wie oben ergänzen.
#[ApiResource] mit operations: [new GetCollection(), new Get()] hinzufügen.
Migration erstellen und anwenden (GENAU wie in Kapitel 9).
AppFixtures um drei Status-Einträge erweitern.
doctrine:fixtures:load ausführen und per curl prüfen.

Achtung: Diese Übung wird in KEINEM späteren Kapitel vorausgesetzt – Block 5 führt die Beziehung zwischen Task und Status UNABHÄNGIG davon selbst ein. Wer die Übung überspringt, verpasst NICHTS für den weiteren Verlauf, festigt aber den Stoff aus Block 2 deutlich schneller durch EIGENES Tun.

Was in Block 3 kommt

Bisher akzeptiert die API JEDES JSON, solange es SYNTAKTISCH gültig ist – ein Project mit LEEREM Namen oder ein Name mit 10.000 Zeichen wird PROBLEMLOS gespeichert. Block 3 (Kapitel 19-28) führt echte VALIDIERUNG ein: Constraints, benutzerdefinierte Fehlermeldungen, Serialisierungsgruppen und die Kontrolle darüber, WELCHE Felder in welcher Situation sichtbar sind.

Tipp: Vor Block 3 lohnt sich ein kurzer Blick zurück auf Kapitel 22 der Symfony-Schulung (Validierungs-Constraints) – API Platform nutzt GENAU dieselbe Symfony-Validator-Komponente, nur AUTOMATISCH in die API-Antworten integriert.