Zeit für Ihr ERSTES echtes Ergebnis: eine minimale, funktionierende API-Ressource, OHNE Datenbank, OHNE Doctrine – NUR um das Grundprinzip zu erleben, bevor Kapitel 9 systematisch fortsetzt.

Eine ApiResource OHNE Doctrine-Entity

API Platform verlangt NICHT zwingend eine Doctrine-Entity – eine EINFACHE PHP-Klasse mit dem #[ApiResource]-Attribut reicht bereits:

<?php

declare(strict_types=1);

namespace App\ApiResource;

use ApiPlatform\Metadata\ApiResource;
use ApiPlatform\Metadata\Get;

#[ApiResource(
    operations: [
        new Get(
            uriTemplate: '/begruessung',
            provider: [self::class, 'liefereBegruessung'],
        ),
    ],
)]
class Begruessung
{
    public string $nachricht = '';

    public static function liefereBegruessung(): self
    {
        $begruessung = new self();
        $begruessung->nachricht = 'Hallo vom Aufgaben-Manager!';

        return $begruessung;
    }
}

provider gibt an, WELCHE Methode die Daten für diese Operation liefert – das "State Provider"-Konzept, das Kapitel 57-58 SYSTEMATISCH vertiefen. Für JETZT reicht: eine statische Methode, die eine Instanz der Klasse zurückgibt.

Die Resource testen

curl -k https://localhost/api/begruessung

{
  "@context": "/api/contexts/Begruessung",
  "@id": "/api/begruessung",
  "@type": "Begruessung",
  "nachricht": "Hallo vom Aufgaben-Manager!"
}

Die @context/@id/@type-Felder stammen aus JSON-LD (Kapitel 3 erwähnt) – zusätzliche, semantische Metadaten, die API Platform STANDARDMÄSSIG mitliefert. Für unser React-Frontend werden wir ab Kapitel 73 meist das einfachere json-Format anfragen, das diese Felder WEGLÄSST.

Kein Cache-Problem: Konfigurationsänderungen wirken sofort

GENAU wie in Kapitel 4 der Symfony-Schulung erklärt: in der Entwicklungsumgebung (Standard für diese Distribution) werden Code- UND Konfigurationsänderungen SOFORT erkannt – kein manuelles cache:clear nötig, um die neue Resource zu sehen.

Was als Nächstes kommt