Flag of Ukraine
SymfonyCasts stands united with the people of Ukraine
This tutorial has a new version, check it out!

Output DTO Class

Keep on Learning!

If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.

Start your All-Access Pass
Buy just this tutorial for $12.00

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

So far, every ApiResource class is either an entity - like CheeseListing and User - or a completely custom class, like DailyStats. With an entity, we can add complex custom fields with some work. We did this in User with our custom isMe and isMvp fields:

... lines 1 - 42
class User implements UserInterface
... lines 45 - 98
* Returns true if this is the currently-authenticated user
* @Groups({"user:read"})
private $isMe = false;
* Returns true if this user is an MVP
* @Groups({"user:read"})
private $isMvp = false;
... lines 112 - 288

And of course, with a custom class like DailyStats that is not an entity... we can do whatever we want! We get to make these classes look exactly like our API. On the downside, these take more time to set up and we lose automatic features like pagination and filtering.

But, like Jean-Luc Picard searching for a solution to an impossible situation, there is a third option, which is kind of "in between" these two.

Why DTO Classes?

In CheeseListing, the input fields look quite different from the output fields. For example, the isPublished field is writable, but it's not readable:

... lines 1 - 60
class CheeseListing
... lines 63 - 102
* @ORM\Column(type="boolean")
* @Groups({"cheese:write"})
private $isPublished = false;
... lines 108 - 219

And the description property is readable, but not writable:

... lines 1 - 60
class CheeseListing
... lines 63 - 81
* @ORM\Column(type="text")
* @Groups({"cheese:read"})
* @Assert\NotBlank()
private $description;
... lines 88 - 219

Well, it is writable, but via a different way: a setTextDescription() method:

... lines 1 - 60
class CheeseListing
... lines 63 - 156
* The description of the cheese as raw text.
* @Groups({"cheese:write", "user:write"})
* @SerializedName("description")
public function setTextDescription(string $description): self
$this->description = nl2br($description);
return $this;
... lines 169 - 219

We accomplished all of this by using smart serialization groups and some custom methods. The upside is that... it's simple! All the logic is in one class. The downside is that... well... it's not actually that simple. Our serialization and deserialization rules are not super clear: you can't quickly look at CheeseListing and figure out which fields are going to be readable or writable.

One solution to this is to have a separate class for your input and output. Basically, we would transform a CheeseListing into another object and then that object would be serialized and returned to the User. We can also do the same thing for the input, which we'll talk about later.

This feature is called input and output DTO's, for data transfer objects. And I love this approach... in theory. Implementing it is pretty clean and it gives you a lot of flexibility. But it's also not a feature that is heavily used by the core API Platform devs. And I found some quirks... some of which are already fixed. I'll walk you through them along the way.

Creating the Output Class

So how do we start? By creating a class that has the exact fields that should exist when a CheeseListing is serialized. In src/, create a new directory called Dto/ and inside, a new PHP class called CheeseListingOutput:

... lines 1 - 2
namespace App\Dto;
class CheeseListingOutput
... line 7

For now let's just have a public $title property:

... lines 1 - 4
class CheeseListingOutput
public $title;

I'm going to use public properties for a few reason. First, these classes should be simple and are only used for our API. And second, if you're using PHP 7.4, you can add types to the properties to guarantee they're set correctly.

Anyways, we'll add more properties later, but let's see if we can get this working.

To tell API Platform that we want to use this as the output class, we need to go back to CheeseListing and, inside the @ApiResource annotation - it doesn't matter where... but I like to put it on top - add output=, take off the quotes and say CheeseListingOutput::class. Go above to add this use statement manually: use CheeseListingOutput:

... lines 1 - 11
use App\Dto\CheeseListingOutput;
... lines 13 - 20
* @ApiResource(
* output=CheeseListingOutput::CLASS,
... lines 24 - 47
* )
... lines 49 - 61
class CheeseListing
... lines 65 - 221

Ok, before we do anything else, let's try it! Find your browser and open a new tab to /api/cheeses.jsonld. And... bah! Error because I always forget my comma. Let's try that again. This time... it... works?

Hmm... it's the exact same result as before. Why? Because right now API Platform is thinking:

Hey! You told me that you wanted to use CheeseListingOutput as your output representation. That's great! But... how do I create that object from a CheeseListing?

Yep! Something needs to transform our CheeseListing objects into CheeseListingOutput objects so that API platform can serialize them. What does that? A data transformer! Let's create one next.

Leave a comment!

Login or Register to join the conversation
Default user avatar
Default user avatar Nemanja Janicev | posted 1 year ago

If I follow example which you provide iti is working fine

Daniel W. Avatar
Daniel W. Avatar Daniel W. | posted 2 years ago

Very nice Tutorial! <3
I wonder if it's possible to modify the query of the dataprovider. For example to filter for Entities with an invisible filter which can't be accessed in the frontend. A Filter that is applied in the backend.


Hey Daniel W.!

Are you looking for this? https://symfonycasts.com/sc...

Let me know!


Daniel W. Avatar

Exactly what I was looking for! Worked flawless for what I needed it.


Yes!!! I love when things “just work” :).

Cat in space

"Houston: no signs of life"
Start the conversation!

This tutorial also works great with API Platform 2.6.

What PHP libraries does this tutorial use?

// composer.json
    "require": {
        "php": ">=8.1",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "api-platform/core": "^2.1", // v2.5.10
        "composer/package-versions-deprecated": "^1.11", // 1.11.99
        "doctrine/annotations": "^1.0", // 1.12.1
        "doctrine/doctrine-bundle": "^2.0", // 2.1.2
        "doctrine/doctrine-migrations-bundle": "^3.0", // 3.0.2
        "doctrine/orm": "^2.4.5", // 2.8.2
        "nelmio/cors-bundle": "^2.1", // 2.1.0
        "nesbot/carbon": "^2.17", // 2.39.1
        "phpdocumentor/reflection-docblock": "^3.0 || ^4.0 || ^5.0", // 5.2.2
        "ramsey/uuid-doctrine": "^1.6", // 1.6.0
        "symfony/asset": "5.1.*", // v5.1.5
        "symfony/console": "5.1.*", // v5.1.5
        "symfony/debug-bundle": "5.1.*", // v5.1.5
        "symfony/dotenv": "5.1.*", // v5.1.5
        "symfony/expression-language": "5.1.*", // v5.1.5
        "symfony/flex": "^1.1", // v1.18.7
        "symfony/framework-bundle": "5.1.*", // v5.1.5
        "symfony/http-client": "5.1.*", // v5.1.5
        "symfony/monolog-bundle": "^3.4", // v3.5.0
        "symfony/security-bundle": "5.1.*", // v5.1.5
        "symfony/twig-bundle": "5.1.*", // v5.1.5
        "symfony/validator": "5.1.*", // v5.1.5
        "symfony/webpack-encore-bundle": "^1.6", // v1.8.0
        "symfony/yaml": "5.1.*" // v5.1.5
    "require-dev": {
        "doctrine/doctrine-fixtures-bundle": "^3.3", // 3.3.2
        "symfony/browser-kit": "5.1.*", // v5.1.5
        "symfony/css-selector": "5.1.*", // v5.1.5
        "symfony/maker-bundle": "^1.11", // v1.23.0
        "symfony/phpunit-bridge": "5.1.*", // v5.1.5
        "symfony/stopwatch": "5.1.*", // v5.1.5
        "symfony/twig-bundle": "5.1.*", // v5.1.5
        "symfony/web-profiler-bundle": "5.1.*", // v5.1.5
        "zenstruck/foundry": "^1.1" // v1.8.0