State Processor sind das SCHREIB-Gegenstück zu Kapitel 57 – ANSTATT Daten zu LESEN, verarbeiten sie Daten NACH der Validierung, VOR der endgültigen Antwort.

Das ProcessorInterface

<?php

declare(strict_types=1);

namespace App\State;

use ApiPlatform\Metadata\Operation;
use ApiPlatform\State\ProcessorInterface;

final class ExampleProcessor implements ProcessorInterface
{
    public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []): mixed
    {
        // $data: das (bereits validierte) Objekt aus dem Request-Body
        // Rückgabe: das Objekt, das der Client in der Antwort sieht
        return $data;
    }
}

$data ist BEREITS das deserialisierte UND validierte Objekt (Block 3) – ein Processor sieht NIEMALS ungültige Daten, die Validierung LÄUFT VORHER, UNABHÄNGIG vom Processor.

Wann Processor statt Doctrine-Lifecycle-Callbacks

Die Symfony-Schulung nutzte Doctrine-#[ORM\PrePersist]-Callbacks für ÄHNLICHE Zwecke – in API Platform sind State Processor die BEVORZUGTE Wahl, da sie AUCH bei Nicht-Doctrine-Ressourcen (Kapitel 60) funktionieren und EXPLIZITER in der #[ApiResource]-Konfiguration SICHTBAR sind.

Den DELETE-Fall beachten

public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []): mixed
{
    if ($operation instanceof \ApiPlatform\Metadata\Delete) {
        // $data ist das zu LÖSCHENDE Objekt, VOR dem Löschen
    }

    return $this->persistProcessor->process($data, $operation, $uriVariables, $context);
}

Mehrere Processor verketten

Ein Processor kann EINEN anderen Processor injizieren und AUFRUFEN – GENAU wie UserPasswordHasherProcessor (Kapitel 48) den STANDARD-Doctrine-Processor umwickelt. Mehrere EIGENE Processor lassen sich theoretisch VERSCHACHTELN, in der PRAXIS bleibt meist EIN Processor pro Resource ÜBERSICHTLICHER.