So far, ALL examples have followed the HAPPY path – now we deliberately BREAK the rules to see HOW API Platform reacts to errors.

Fetching a non-existent item

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 AUTOMATICALLY, as soon as Doctrine finds NO item with that id – WITHOUT us writing any check ourselves.

Sending invalid JSON

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

HTTP/2 400

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

Status 400 Bad Request – the JSON parser fails BEFORE our entity even comes into play. IMPORTANT: this is a DIFFERENT error type than a failed VALIDATION (block 3), where the JSON is syntactically CORRECT but the content is invalid.

Overview of the most important status codes

Mapping custom exceptions to HTTP status codes

EXACTLY as in the Symfony course (chapter 27), CUSTOM exceptions can be mapped to a specific status code via the #[WithHttpStatus] attribute – relevant once CUSTOM business logic exceptions are added in block 7.