Bisher liefen ALLE Beispiele den GLÜCKLICHEN Pfad entlang – jetzt wird bewusst GEGEN die Regeln verstoßen, um zu sehen, WIE API Platform auf Fehler reagiert.

Ein nicht existierendes Element abrufen

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

HTTP/2 404
content-type: application/ld+json; charset=utf-8

{
  "@context": "/api/contexts/Error",
  "@type": "hydra:Error",
  "hydra:title": "An error occurred",
  "hydra:description": "Not Found"
}

Status 404 Not Found AUTOMATISCH, sobald Doctrine KEIN Element mit dieser id findet – OHNE dass wir irgendeine Prüfung selbst geschrieben haben.

Ungültiges JSON senden

curl -k -i -X POST https://localhost/api/projects \
  -H 'Content-Type: application/json' \
  -d '{ungültiges json'

HTTP/2 400

{
  "@context": "/api/contexts/Error",
  "@type": "hydra:Error",
  "hydra:title": "An error occurred",
  "hydra:description": "Syntax error"
}

Status 400 Bad Request – der JSON-Parser scheitert, BEVOR unsere Entity überhaupt ins Spiel kommt. WICHTIG: das ist ein ANDERER Fehlertyp als eine fehlgeschlagene VALIDIERUNG (Block 3), bei der das JSON syntaktisch KORREKT, aber INHALTLICH ungültig ist.

Übersicht der wichtigsten Statuscodes

Eigene Exceptions auf HTTP-Statuscodes abbilden

GENAU wie in der Symfony-Schulung (Kapitel 27) lassen sich EIGENE Exceptions über das Attribut #[WithHttpStatus] auf einen bestimmten Statuscode abbilden – relevant, sobald in Block 7 EIGENE Geschäftslogik-Exceptions hinzukommen.