Kapitel 37 zeigte den Grundfall – dieses Kapitel geht auf FEHLERFÄLLE beim Verknüpfen ein und zeigt den Weg über den verschachtelten Endpunkt aus Kapitel 39.

Verknüpfung mit ungültiger IRI

curl -k -X POST https://localhost/api/tasks \
  -H 'Content-Type: application/json' \
  -d '{"title": "Test", "project": "/api/projects/99999"}'

{
  "violations": [
    {"propertyPath": "project", "message": "Item not found for \"/api/projects/99999\"."}
  ]
}

Status 422 – API Platform LÖST die IRI AUF, BEVOR gespeichert wird, und meldet einen VALIDIERUNGSFEHLER, wenn das Ziel NICHT existiert, GENAU im gleichen violations-Format aus Kapitel 20.

Verknüpfung mit falschem Ressourcentyp

curl -k -X POST https://localhost/api/tasks \
  -H 'Content-Type: application/json' \
  -d '{"title": "Test", "project": "/api/tags/1"}'

EBENFALLS 422 – /api/tags/1 ist eine SYNTAKTISCH gültige IRI, aber vom FALSCHEN Typ (Tag statt Project). API Platform PRÜFT den Zieltyp, nicht nur die Existenz.

Über den verschachtelten Endpunkt erstellen

Der Sub-Resource-Pfad aus Kapitel 39 (/api/projects/{projectId}/tasks) hatte in unserem Beispiel NUR GetCollection – für POST über diesen Pfad müsste die Operation-Liste um new Post() ERWEITERT werden:

operations: [new GetCollection(), new Post()],

curl -k -X POST https://localhost/api/projects/1/tasks \
  -H 'Content-Type: application/json' \
  -d '{"title": "Deployment vorbereiten"}'

OHNE explizites project-Feld im Body – API Platform setzt es AUTOMATISCH aus der URL (projectId), da Link (Kapitel 39) diese Verbindung BEREITS kennt.