Block 2 Summary: Building Your Own Resource
Block 2 Summary: Building Your Own Resource
~16 Min. Lesezeit Zuletzt aktualisiert am August 8, 2026
Block 2 is COMPLETE. Before block 3 CONTINUES with serialization and validation, this chapter summarizes EVERYTHING learned so far – AND has you APPLY it yourself.
What block 2 covered
- Chapter 9:
#[ApiResource]generates automatic CRUD from a Doctrine entity. - Chapter 10: all six default operations tested individually with
curl. - Chapter 11: operations understood as concrete PHP classes (
Get,Post, ...). - Chapter 12: read-only resources by omitting classes (
Tag). - Chapter 13: custom
uriTemplatepaths per resource and per operation. - Chapter 14:
shortName,description, anddeprecatedfor better docs. - Chapter 15: reproducible test data via Doctrine fixtures.
- Chapter 16: status codes and error behavior for invalid requests.
- Chapter 17: exported the OpenAPI specification and imported it into Postman.
Project state at the end of block 2
api/src/ – state after chapter 17
api/
└── src/
├── Entity/
│ ├── Project.php ← #[ApiResource], full CRUD
│ └── Tag.php ← #[ApiResource], READ-ONLY
├── Repository/
│ ├── ProjectRepository.php
│ └── TagRepository.php
└── DataFixtures/
└── AppFixtures.php ← 2 tags + 1 projectApply it yourself: the Status entity
As this block's CLOSING EXERCISE: create a THIRD entity Status YOURSELF (fields: label string, color string) – EXACTLY like Tag, it should be READ-ONLY through the API (only GetCollection and Get), with its own fixtures (e.g. "Open", "In Progress", "Done").
- Run
bin/console make:entity Status, add the fields above. - Add
#[ApiResource]withoperations: [new GetCollection(), new Get()]. - Create and apply a migration (EXACTLY as in chapter 9).
- Extend
AppFixtureswith threeStatusentries. - Run
doctrine:fixtures:loadand verify withcurl.
Achtung: This exercise is NOT assumed in ANY later chapter – block 5 introduces the relationship between Task and Status INDEPENDENTLY of it. Skipping the exercise means missing NOTHING for the rest of the course, but doing it yourself cements block 2's material much faster.
What's coming in block 3
So far the API accepts ANY JSON as long as it's SYNTACTICALLY valid – a Project with an EMPTY name or a name with 10,000 characters gets saved WITHOUT ISSUE. Block 3 (chapters 19-28) introduces real VALIDATION: constraints, custom error messages, serialization groups, and control over WHICH fields are visible in which situation.
Tipp: Before block 3, it's worth a quick look back at chapter 22 of the Symfony course (validation constraints) – API Platform uses EXACTLY the same Symfony Validator component, just AUTOMATICALLY wired into the API responses.