Block 3 ist ABGESCHLOSSEN. Aus einer API, die JEDES beliebige JSON annahm, ist eine API geworden, die GEZIELT prüft, was sie speichert, und GEZIELT steuert, was sie zurückgibt.

Was Block 3 behandelt hat

• Kapitel 19: #[Assert\NotBlank]/#[Assert\Length], automatische Validierung bei POST/PUT/PATCH.
• Kapitel 20: das violations-Array im Detail, Abgrenzung 400 vs. 422.
• Kapitel 21: weitere Constraints, eigene Fehlermeldungen mit Platzhaltern.
• Kapitel 22: Validierungsgruppen vs. Serialisierungsgruppen als GRUNDVERSCHIEDENE Konzepte.
• Kapitel 23: normalizationContext und #[Groups] fürs Lesen.
• Kapitel 24: denormalizationContext fürs Schreiben, geschützte Felder.
• Kapitel 25: berechnete Felder ohne Datenbankspalte (isRecent).
• Kapitel 26: ein eigener Validator (UniqueProjectName).
• Kapitel 27: DTOs als Alternative zu Gruppen, wenn das Antwortformat stärker abweicht.

Projektstand am Ende von Block 3

api/
└── src/
    ├── Entity/
    │   ├── Project.php   ← Validierung + Gruppen + berechnetes Feld
    │   └── Tag.php       ← weiterhin schreibgeschützt
    ├── Dto/
    │   └── ProjectSummary.php  ← Konzept, noch OHNE Provider
    ├── Validator/
    │   ├── UniqueProjectName.php
    │   └── UniqueProjectNameValidator.php
    └── DataFixtures/
        └── AppFixtures.php

Selbst anwenden: die Status-Entity vervollständigen

Falls die Übung aus Kapitel 18 (eine eigene Status-Entity) umgesetzt wurde: ergänzen Sie #[Assert\NotBlank] auf label und #[Assert\Choice(choices: ['#dc2626', '#f59e0b', '#16a34a'])] auf color, sowie #[Groups(['status:read'])] auf BEIDEN Feldern.

Was in Block 4 kommt

Bisher liefert GET /api/projects IMMER ALLE Projekte auf EINMAL – bei hunderten oder tausenden Einträgen WEDER praktikabel NOCH performant. Block 4 (Kapitel 29-36) führt Pagination, Filterung nach Feldwerten und Sortierung ein – ALLES ohne eine EINZIGE Zeile eigenen Query-Codes, GENAU wie das automatische CRUD aus Block 2.