Serialisierungsgruppen reichen für die MEISTEN Fälle – manchmal soll das API-Antwortformat aber STRUKTURELL vom Entity-Aufbau ABWEICHEN. Dafür gibt es DTOs (Data Transfer Objects).

Wann Gruppen nicht mehr ausreichen

• Die API-Antwort soll Felder aus MEHREREN Entities KOMBINIEREN (z. B. Projekt + Anzahl Tasks in EINEM flachen Objekt).
• Das externe API-Format soll UNABHÄNGIG von internen Refactorings der Entity bleiben (Versionierung/Stabilität).
• Berechnungslogik ist zu KOMPLEX für eine einzelne Getter-Methode (Kapitel 25) und verdient eine EIGENE Klasse.

Ein Output-DTO definieren

<?php

declare(strict_types=1);

namespace App\Dto;

final class ProjectSummary
{
    public int $id;
    public string $name;
    public bool $isRecent;
}

EINE einfache, reine Datenklasse OHNE Doctrine-Attribute, OHNE Validierung – ein DTO beschreibt NUR die FORM der API-Antwort, nicht die Speicherung.

Das DTO an eine Operation binden

use App\Dto\ProjectSummary;

new Get(
    uriTemplate: '/projects/{id}/summary',
    output: ProjectSummary::class,
    provider: ProjectSummaryProvider::class,
),

output legt fest, WELCHE Klasse API Platform statt der Entity serialisiert – ein provider (ein STATE PROVIDER, GENAU das Prinzip aus Kapitel 5) übernimmt die eigentliche BEFÜLLUNG des DTOs aus der echten Project-Entity.

DTOs vs. Gruppen: eine Entscheidungshilfe