Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

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 uriTemplate paths per resource and per operation.
  • Chapter 14: shortName, description, and deprecated for 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 project

Apply 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").

  1. Run bin/console make:entity Status, add the fields above.
  2. Add #[ApiResource] with operations: [new GetCollection(), new Get()].
  3. Create and apply a migration (EXACTLY as in chapter 9).
  4. Extend AppFixtures with three Status entries.
  5. Run doctrine:fixtures:load and verify with curl.

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.