What about API Platform 3 Part 4: Using graphql to the fullest?

HI, could you add an extra chapter about filters? I don't see how they work with custom resources. Is there an easy way to make it work?

Yes!!

This is the course I've been waiting.

Looking forward to it! :)

This course leads to an incomplete setup when using a custom resource with a different input and output format (either distinct DTO classes or when using serialization groups). The 'output' property and the 'normalizationContext' on both the resource and operation are ignored, so POST requests will return the input DTO.

I solved this by mapping to the output DTO and returning this object at the end of the process method in the state processor.

...

class DtoToEntityStateProcessor implements ProcessorInterface
{
    ...
    
    public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []): mixed
    {
        ...

        return $this->microMapper->map($entity, OutputDto::class, [
            MicroMapperInterface::MAX_DEPTH => 1
        ]);
    }

I am posting this here in case anyone runs into the same issue, as this took me multiple days to track down.

Otherwise, I really appreciated this course. I think having a distinct input and output format are a common use case, so updating the course to include this gotcha could be very helpful for folks.

This was a really nice course!

There is just one Issue i'm facing with the DTO and related Objects.
Lets take the DragonTreasureApi file. In that DTO we have the property: $owner which is of type: UserApi so far so good.

Calling the Endpoint (Get / GetCollection) to fetch the DragonTreasures we get a result like this:

{
  "@context": "/api/contexts/Treasure",
  "@id": "/api/treasures/1",
  "@type": "Treasure",
  "name": "collection of novelty mugs with silly sayings",
  "description": "xxxx",
  "value": 847274,
  "coolFactor": 8,
  "owner": "/api/users/3",
  "shortDescription": "Laboriosam officia dolorem aut rerum....",
  "plunderedAtAgo": "1 day ago",
  "isMine": false
}

As we can see, the property owner is currently the IRI, still, so far so good.

Now the Issue. I want to have the property populated with the UserApi Object, instead of only the IRI.
Therefore i've changed the MicroMapperInterface::MAX_DEPTH => 0 to 1 (tried with multiple values, like 10, null etc.) in the DragonTreasureEntityToApiMapper.php File.
In my opinion, the property owner should now be populated with the UserApi Object instead of the IRI.

Dumping the $dto inside the DragonTreasureEntityToApiMapper.php file also shows, that the DTO contains the populated UserApi Object

What am i doing wrong here?

Hello,
Thanks for the Course.
I think there might be a bug in the chapter 36 of this part 3.
In the src/Validator/TreasuresAllowedOwnerChangeValidator.php file, there is a return statement in the loop :

foreach ($value->dragonTreasures as $dragonTreasureApi) {
    assert($dragonTreasureApi instanceof DragonTreasureApi);
    $originalOwnerId = $dragonTreasureApi->owner?->id;
    $newOwnerId = $value->id;
    if (!$originalOwnerId || $originalOwnerId === $newOwnerId) {
        return; // <-- HERE !
    }
    // the owner is being changed
    $this->context->buildViolation($constraint->message)
        ->addViolation();
}

I think this will be problematic when configuring multiple IRIs. Would't that check only the first DragonTreasureApi instance ? then if the first is owned by the user, the others won't be checked ?
As it is far in the course, the problem might come in earlier chapters.

In a completely other subject, I saw you talked about releasing a new episode. It might be good to see how to handle file upload, I followed the official documentation and I had a really difficult time to set it up ;)

This is a really nice way to design APIs, I really love it! This look so much clearer than having tons of serialization groups everywhere, and having calculated field in dedicated classes is so nicer than having them in entities.

But whoa, if you're going to deal with several entities, you better have a nice AI companion to code with you or it'll be a real pain to write all you Api, EntityToApiMapper and *ApiToEntityMapper.
I'd probably gave up while creating these 3 files manually for each Entity, as it is so time consuming and off-putting.

Hi,
as response from POST and PATCH requests we get the serialized resource,
like when i do a GET request. i noticed that changes to the resource that not coming from my POST/PATCH requests are not updated and reflected in the response. an example is an automatically changed property like "updatedAt". instead there is the old value or nothing at all when the value was not set before.
In the follow up requests i see the changes.
Is there an elegant way to ensure that i get the actual state of the resource?
What i tried so far is:
a) in the Dto2Entity Mapper also setting the Dto properties. It works, but at this point i dont have all infos, for example updatedAt coming from an doctrine event.
b) in the processor where you set the id of the generated entity back to the dto. That works but there have to be some sort of callback/hook mechanism for a generic processor.
c) similar to b) not really tested, but is it a good idea to simply call the micromapper and overwrite the dto by mapping the entity back to it?

Thanks for your great tutorials.
Peter

Hello, a great course :)

I just have one question. Maybe, I have missed it but we saw how to persist embedded objects with Groups but what about the same case with DTOs?

Is it possible to create nested objects via DTOs? For instance I am trying to persist a new User object with liked Profile object (1:1 in the particular case). I am using the microMapper but now I got an error "400 Nested documents for attribute \"profile\" are not allowed. Use IRIs instead.". If I use serialization Groups I do get to save both objects but it does not retrieve any fields, besides the LD+JSON ones @id, @type.

Everything in all the mappers seems OK.

Example Post Request body:

{
  "email": "test-email@example.com",
  "password": "123456",
  "profile": {
    "firstName": "FirstName",
    "middleName": "MiddleName",
    "lastName": "LastName"
  }
}