denormalizationContext ist das GEGENSTÜCK zu Kapitel 23 – es steuert, WELCHE Felder ein POST/PUT/PATCH-Request ÜBERHAUPT annimmt.

denormalizationContext hinzufügen

#[ApiResource(
    normalizationContext: ['groups' => ['project:read']],
    denormalizationContext: ['groups' => ['project:write']]
)]
#[ORM\Entity(repositoryClass: ProjectRepository::class)]
class Project
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    #[Groups(['project:read'])]
    private ?int $id = null;

    #[ORM\Column(length: 255)]
    #[Assert\NotBlank]
    #[Groups(['project:read', 'project:write'])]
    private string $name = '';

    #[ORM\Column(type: 'text', nullable: true)]
    #[Groups(['project:read', 'project:write'])]
    private ?string $description = null;

    #[ORM\Column]
    #[Groups(['project:read'])]
    private \DateTimeImmutable $createdAt;

    // ... Rest unverändert
}

id und createdAt gehören NUR zu project:read – sie DÜRFEN nicht vom Client gesetzt werden (die id wird von der Datenbank vergeben, createdAt im Konstruktor). name und description gehören zu BEIDEN Gruppen: lesbar UND schreibbar.

Das Verhalten testen

curl -k -X POST https://localhost/api/projects \
  -H 'Content-Type: application/json' \
  -d '{"name": "Neues Projekt", "id": 999, "createdAt": "1970-01-01T00:00:00+00:00"}'

id und createdAt im Request-Body werden STILLSCHWEIGEND IGNORIERT – KEIN Fehler, aber auch KEINE Wirkung, da sie NICHT in project:write enthalten sind. Die Datenbank vergibt weiterhin ihre EIGENE id, der Konstruktor weiterhin sein EIGENES createdAt.

Warum nicht einfach eine readonly-Eigenschaft?

PHPs eigenes readonly-Schlüsselwort würde bei JEDEM Schreibversuch einen FATALEN Fehler auslösen – Serialisierungsgruppen dagegen IGNORIEREN den Wert einfach STILL, was für ein API-Feld das GEWÜNSCHTE, tolerantere Verhalten ist (ein Client, der versehentlich id mitschickt, soll NICHT abstürzen).