API Platform now provides good extension points that work for REST and GraphQL APIs the same time. The docs should be updated to explicitly discourage using custom controllers AND Symfony Kernel's events, and instead encourage to use the following extension points:

• Data Provider: Fetch data, custom computation, custom hydration

  • Alternative when using the built-in Doctrine data provider: use extensions and create custom Doctrine hydrators

  To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Symfony Denormalizer: to customize the object computed from the JSON payload
Symfony Voter: to hook custom authorization logic
Symfony Validation constraint: to hook custom validation logic
Data Persister: to hook custom business logic or computation to trigger before, during or after persistence (ex: mail, call to an external API…)
Symfony Normalizer: to customize the output (add field in the JSON, encode codes, dates…)
Symfony Messenger integration: to create RPC, async, service-oriented endpoints, should be used in place of custom controllers (because the messenger integration is compatible with both REST and GraphQL, while custom controllers only work with REST)
DTOs and data transformers: to create specialized representations of a (usually large) object or graph of objects also available through their own endpoints (for internal objects, a simple data provider and a public @ApiResource must be used instead). Using DTOs and data transformers should be rare. In most cases, using a class marked with @ApiResource representing the public data model exposed through the API (this class don't have to be mapped with a Doctrine entity, as explained here https://api-platform.com/docs/core/design/). It must not be tight to the internal data model. It's the responsibility of the Data Provider to fetch data from the persistence system and to convert it to a @ApiResource class. Data Transformers must not be used for this purpose.
Symfony Kernel Event Listener: Customize the HTTP request or response (REST only, last resort solution)
TODO: use the error handler (new component) to hook custom error handling logic (see also Fix compatibility with symfony/error-renderer core#2972)