Jetzt beginnt die EIGENTLICHE Arbeit: unsere ERSTE echte Doctrine-Entity, Project, wird durch EIN Attribut zu einer vollständigen API.

Die Project-Entity anlegen

docker compose exec php bin/console make:entity Project

GENAU derselbe make:entity-Befehl aus der Symfony-Schulung (Kapitel 19) – Felder: name (string, 255), description (text, nullable), createdAt (datetime_immutable).

#[ApiResource] hinzufügen

<?php

declare(strict_types=1);

namespace App\Entity;

use ApiPlatform\Metadata\ApiResource;
use App\Repository\ProjectRepository;
use Doctrine\ORM\Mapping as ORM;

#[ApiResource]
#[ORM\Entity(repositoryClass: ProjectRepository::class)]
class Project
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\Column(length: 255)]
    private string $name = '';

    #[ORM\Column(type: 'text', nullable: true)]
    private ?string $description = null;

    #[ORM\Column]
    private \DateTimeImmutable $createdAt;

    public function __construct()
    {
        $this->createdAt = new \DateTimeImmutable();
    }

    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;
    }

    public function getDescription(): ?string
    {
        return $this->description;
    }

    public function setDescription(?string $description): static
    {
        $this->description = $description;

        return $this;
    }

    public function getCreatedAt(): \DateTimeImmutable
    {
        return $this->createdAt;
    }
}

GENAU EIN Unterschied zu einer normalen Symfony-Entity: die Zeile #[ApiResource]. ALLES ANDERE (Attribute, Getter/Setter) ist IDENTISCH zur Symfony-Schulung.

Migration erstellen und anwenden

docker compose exec php bin/console make:migration
docker compose exec php bin/console doctrine:migrations:migrate --no-interaction

GENAU derselbe Fünf-Schritte-Workflow aus Kapitel 20 der Symfony-Schulung – Migrationen funktionieren in API Platform UNVERÄNDERT, da darunter GANZ NORMALES Doctrine/Symfony steckt.

Was jetzt bereits funktioniert

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

{
  "@context": "/api/contexts/Project",
  "@id": "/api/projects",
  "@type": "hydra:Collection",
  "hydra:member": [],
  "hydra:totalItems": 0
}

Eine LEERE Liste (noch keine Projekte in der Datenbank), aber ein VOLLSTÄNDIG funktionierender Endpunkt – hydra:member ist der Ort, an dem die eigentlichen Projekte erscheinen werden, sobald welche existieren (Kapitel 10).

Wie API Platform den Endpunkt-Namen ableitet

/api/projects statt /api/project: API Platform PLURALISIERT den Klassennamen AUTOMATISCH (Project → projects) für Sammlungs-Endpunkte – GENAU dieselbe Konvention wie in den MEISTEN modernen REST-APIs, inklusive der Magento REST API aus unseren separaten Tutorials.