Block 6 nutzte State Provider PRAGMATISCH, OHNE das Konzept zu erklären – dieses Kapitel holt das VOLLSTÄNDIG nach: WIE liest API Platform Daten ÜBERHAUPT, und WARUM lässt sich das AUSTAUSCHEN?

Der Standard-Provider: unsichtbar, aber immer da

JEDE #[ApiResource]-Operation OHNE explizites provider-Attribut nutzt INTERN einen Doctrine-basierten STANDARD-Provider – GENAU DAS, was seit Kapitel 9 im Hintergrund passiert, OHNE dass wir je einen Provider SELBST geschrieben hätten.

Das ProviderInterface

<?php

declare(strict_types=1);

namespace App\State;

use ApiPlatform\Metadata\Operation;
use ApiPlatform\State\ProviderInterface;

final class ExampleProvider implements ProviderInterface
{
    public function provide(Operation $operation, array $uriVariables = [], array $context = []): mixed
    {
        // Für eine Item-Operation: EIN Objekt (oder null) zurückgeben.
        // Für eine Collection-Operation: ein iterable zurückgeben.
        return null;
    }
}

NUR EINE Methode, provide() – die RÜCKGABE hängt vom Operation-Typ ab: Get erwartet EIN Objekt (oder null für 404), GetCollection erwartet ein iterable.

Wrapping vs. Ersetzen

OwnProjectsCollectionProvider aus Kapitel 55 ERSETZTE die Abfrage KOMPLETT (findBy() statt der Standard-Query) – ProjectOwnerProcessor aus Kapitel 54 WRAPPTE dagegen NUR ZUSÄTZLICHE Logik UM den Standard-Ablauf HERUM.

Wann welche Strategie

• WRAPPING: für ZUSÄTZLICHE Seiteneffekte (Hashing, automatisches Setzen von Feldern, Logging) – der GRUNDABLAUF bleibt Doctrine-basiert.
• ERSETZEN: wenn die Datenquelle NICHT die Datenbank ist (externe API, Cache, berechnete Werte) ODER die Abfragelogik STRUKTURELL abweicht (Kapitel 55).

Den Provider registrieren

new Get(provider: ExampleProvider::class),

GENAU dieselbe Syntax wie processor: – provider lässt sich AUF Resource-Ebene (gilt für ALLE lesenden Operationen) ODER AUF Operation-Ebene (NUR für DIESE eine) setzen.