NICHT jede Resource soll VOLL beschreibbar sein. Als KONKRETES Beispiel führen wir eine ZWEITE Entity ein: Tag – Referenzdaten, die NUR per Fixtures (Kapitel 15) angelegt werden, NIEMALS über die API.

Die Tag-Entity anlegen

docker compose exec php bin/console make:entity Tag

<?php

declare(strict_types=1);

namespace App\Entity;

use ApiPlatform\Metadata\ApiResource;
use ApiPlatform\Metadata\Get;
use ApiPlatform\Metadata\GetCollection;
use App\Repository\TagRepository;
use Doctrine\ORM\Mapping as ORM;

#[ApiResource(
    operations: [
        new GetCollection(),
        new Get(),
    ]
)]
#[ORM\Entity(repositoryClass: TagRepository::class)]
class Tag
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\Column(length: 100, unique: true)]
    private string $name = '';

    public function getId(): ?int
    {
        return $this->id;
    }

    public function getName(): string
    {
        return $this->name;
    }

    public function setName(string $name): static
    {
        $this->name = $name;

        return $this;
    }
}

NUR ZWEI Klassen in der operations-Liste: GetCollection und Get. Post, Put, Patch und Delete fehlen KOMPLETT – API Platform generiert für sie GAR KEINE Route.

Das Verhalten testen

curl -k -X POST https://localhost/api/tags \
  -H 'Content-Type: application/json' \
  -d '{"name": "Dringend"}'

{
  "@context": "/api/contexts/Error",
  "@type": "hydra:Error",
  "hydra:title": "An error occurred",
  "hydra:description": "No route found for \"POST /api/tags\""
}

Wann sich schreibgeschützte Resources lohnen

• Referenz-/Lookup-Daten (Tags, Kategorien, Status-Werte), die zentral über Fixtures oder ein Admin-Panel gepflegt werden.
• Berechnete oder aggregierte Daten (z. B. eine Statistik-Resource), bei denen Schreiben KONZEPTIONELL keinen Sinn ergibt.
• Daten aus EXTERNEN Systemen, die über API Platform nur GESPIEGELT, nicht VERÄNDERT werden sollen.

Noch enger: nur GetCollection, kein Get

Genauso lässt sich Get WEGLASSEN und NUR GetCollection behalten – dann existiert AUSSCHLIESSLICH GET /api/tags, aber KEIN GET /api/tags/{id} für ein einzelnes Element. In der Praxis ist das SELTEN sinnvoll, zeigt aber, wie GRANULAR sich die Liste steuern lässt.