Unable to deserialize IRI in requestDto to User object

[arthurGrinjo]

I am running into the issue where I am unable to create new objects with a relation in it.

In this simplified project I have two entities; Activity and User where every Activity is related to a User. I have a DecorateObjectMapper however it is still unused and I created a standardProcessor which is also quite basic until now.

Everything works fine for all (GET/POST/PUT/DELETE) operations. However I'm unable to make a new Activity Object via the API, it fails to resolve the IRI to an User object. The ActivityRequestDto becomes a valid object, however it does not contain the proper values.

Anyone a solution? I tried Mapping annotations, map true/false in the operation (ApiResource/Activity.php), running out of ideas now...

Project: https://github.com/arthurGrinjo/PostRelation
There are 2 branches, one with and one without PHPunit.

[arthurGrinjo]

Possible solution I'm working on right now:

Making user property in ActivityRequestDto a string, validate it with Regex validation. Via the standardProcessor it is forwarded to the DecorateObjectMapper where I possibly can convert the User IRI into a user. With this I can create a new Activity Object.

The original ObjectMapper fails because while Mapping it converts into a UserResponseDto.

[yudin-s]

I would keep your request DTO's user field as an IRI string and resolve it in the processor. In your current repro, the failing boundary is that the client sends something like /users/{uuid}, but ActivityRequestDto asks Symfony's ObjectMapper for an App\Entity\User:

#[Map(target: User::class)]
public User $user;

That #[Map] attribute is not an API Platform IRI resolver. It can map object properties, but it does not know that a JSON string IRI should be loaded through API Platform's route/resource metadata and then turned into the Doctrine entity. In your project that is especially easy to trip over because you have separate API resource classes (App\ApiResource\User) and entity classes (App\Entity\User), with stateOptions mapping the resource to the entity.

So the DTO should model what the request actually contains:

final class ActivityRequestDto implements RequestDto
{
    #[Assert\Length(min: 4, max: 128)]
    public string $name;

    #[Assert\NotBlank]
    public string $user; // "/users/{uuid}"
}

Then, in the processor, resolve that IRI before setting the relation:

use ApiPlatform\Metadata\IriConverterInterface;
use App\ApiResource\User as UserResource;
use App\Dto\Activity\Request\ActivityRequestDto;
use App\Entity\User as UserEntity;

public function __construct(
    private EntityManagerInterface $entityManager,
    private ObjectMapperInterface $objectMapper,
    private IriConverterInterface $iriConverter,
    // ...
) {}

// inside the Activity POST branch
if ($data instanceof ActivityRequestDto && $entity instanceof ActivityEntity) {
    $user = $this->iriConverter->getResourceFromIri(
        $data->user,
        ['resource_class' => UserResource::class],
    );

    if (!$user instanceof UserEntity) {
        throw new RuntimeException('Invalid user IRI.');
    }

    $entity->setName($data->name);
    $entity->setUser($user);
}

You can still keep your generic StandardProcessor, but relations need either a small per-DTO branch like the above or a deliberate convention in your decorator, for example "properties ending in Iri are resolved with IriConverterInterface before mapping." Trying to make the request DTO property itself an entity is what pushes the deserializer/object mapper into the wrong job.

That also explains why your DecorateObjectMapper does not help early enough: the request body has to be denormalized into ActivityRequestDto before your later DTO-to-entity mapping can run. At that stage, API Platform sees a scalar IRI string, while the DTO property says User.

So your proposed string-field approach is the right direction. I would just use IriConverterInterface::getResourceFromIri() in the processor instead of regex-only validation, because the converter both validates that the IRI is an API Platform resource IRI and gives you the loaded object to assign to the Doctrine relation.

If that fixes the POST path, please mark this as answered so the next person does not chase #[Map] for IRI conversion.

[arthurGrinjo]

Hi Serge,

Thanks for your detailed answer. Moving the IRI conversion from the mapper to the processor really helped me out!

I even don't need the decorated mapper now. Main issue was the mapper's functionality which broke due to the #[Map(target: UserResponseDto::class] above the User Entity. This corrupted the mapping process resulting in ending up with a responseDto instead of a User object. I managed to fix this with: #[Map(target: UserResponseDto::class, if: new TargetClass(ResponseDto::class))] (please have a look at my test branch if you want to see it working)

Just still not able to use the api-platform logic to convert IRI's automatically into objects.. Which is a pity. That might result in not even a generic processor. However happy with the working result for now. :)

[soyuka]

Interesting but I'd do like this: Let API Platform resolve the IRI, the issue is that ActivityRequestDto::$user is typed with App\Entity\User which is not a resource. Type it with a resource class and the serializer will turn /users/{uuid} into that resource for you.

The User resource only needs its identifier and a mapping from the entity:

#[Get(
    shortName: 'User',
    stateOptions: new Options(entityClass: UserEntity::class),
)]
#[Map(source: UserEntity::class)]
final class UserResource
{
    public Uuid $id;
}

Your DTO is not mapped to anything, it only uses the resource:

final class ActivityRequestDto
{
    #[Assert\Length(min: 4, max: 128)]
    public string $name;

    #[Assert\NotNull]
    public ?UserResource $user = null;
}

Then in your processor you get the entity from the id, no IRI parsing needed:

$activity = new ActivityEntity();
$activity->setName($data->name);
$activity->setUser($this->entityManager->getReference(UserEntity::class, $data->user->id));

$this->entityManager->persist($activity);
$this->entityManager->flush();

An invalid or unknown IRI is rejected by the serializer before your processor runs.

[arthurGrinjo]

Hi Antoine,

Thing is I'm stuck in a loop... Let's try to explain. I'm now working in my final (working!) result until now: test-branch

For GET operations on User I'm having UserCollectionResponseDto and UserResponseDto returned which is fine.

For GET operations on Activity I had to add #[Map(target: UserResponseDto::class)] to the App\Entity\User otherwise I'm not able to create the user-response inside the ActivityResponseDto or ActivityCollectionResponseDto which can be the sub-resource of User or an IRI based on the setting readableLink: true/false.

And this setup comes with the issue: Not able to deserialize an IRI into a User-object. Because I added if: new TargetClass(ResponseDto::class) to the Map() in App\Entity\User I am able to use the Mapper logic again. That failed because getResourceFromIri() returned a UserResponseDto beforehand.

Other thing I was able to do was deserializing the IRI into a UserResponseDto but this also doesn't help me out. I need a User-object.

Perhaps you could give it a try in my test-branch? I'm rather happy with the result until now, however would be nice to use the API-platform logic for deserialization of the IRI's.

[soyuka]

Gave it a try, see arthurGrinjo/PostRelation#1

The loop comes from the DTOs: an IRI resolves to what your API exposes, and your User operations expose UserResponseDto, so that's what getResourceFromIri() returns. You'll never get the entity from an IRI when using stateOptions, and it's by design.

Instead, drop the DTOs and make the classes carrying the operations your resources (no #[ApiResource], one class per shape):

#[Get(uriTemplate: 'users/{uuid}', shortName: 'user', stateOptions: new Options(entityClass: UserEntity::class))]
#[Map(target: UserEntity::class, transform: UserResourceToEntity::class)]
#[Map(source: UserEntity::class)]
final class User
{
    #[ApiProperty(identifier: true)]
    public Uuid $uuid;
    public string $email;
    public string $firstName;
    public string $lastName;
}

#[Post(uriTemplate: 'activities', shortName: 'activity', stateOptions: new Options(entityClass: ActivityEntity::class))]
#[Map(source: ActivityEntity::class, target: ActivityEntity::class)]
final class Activity
{
    public string $name;

    #[ApiProperty(readableLink: true)]
    public User $user;
}

Activity::$user is typed with the resource so the serializer resolves /api/users/<uuid> (and returns a 400 when it doesn't exist), and the User resource maps itself to the managed entity with a small transform (a findOneBy(['uuid' => ...])). The default PersistProcessor does the rest, no custom processor needed.

Note that you need Symfony 8.1, it's the ObjectMapper reverse class-map that reads #[Map(source: UserEntity::class)] on the resource for the nested user, so the entity doesn't need any #[Map].

[arthurGrinjo]

Wow Antoine! Deep bow! 🙏

I was not able to manage this until now! Will read it more careful to really understand how you did this but it really seems to work. Many thanks!! In this way I'm able to implement this 'DTO-structure' and still rely on the api platform logic.

The files under ApiResource are now the new DTO's and I could also add ActivityTestRequest here I suppose? 🧐

Yes I think this is the correct solution to rely on Api-Platform logic and have Dto's implemented.

[arthurGrinjo]

So finally diving deep I do understand what you did. The transformer reverts the ResponseDto back to the User object. Nice solution. 👌

[arthurGrinjo]

@soyuka one question left: Registering a user works however, where does the response come from?! It seems it is not based on App\ApiResource\User or App\ApiResource\UserListItem because removing first_name from these files doesn't show a different response..

E.g. :

{
"@context": "/api/contexts/user",
"@id": "/api/users/1f1bcc72-4600-6310-84c2-5d00d659eb71",
"@type": "user",
"uuid": "1f1bcc72-4600-6310-84c2-5d00d659eb71",
"email": "new_user@domain.com",
"first_name": "First",
"last_name": "Last"
}

Ahh.. I see, it's just returning the sent data. And removes the password with #[ApiProperty(readable: false)]. And it seems not to be possible return a App\ApiResource\User.php No problem. I totally understand the logic now. 👍

[arthurGrinjo]

@soyuka So I continued on your input and came up with one question about this setup. I tried to remove the name from the ActivityResponseDto. That seems to be an issue; Can't get a way to read the property "name" in class "App\ApiResource\Activity\Response\ActivityCollectionResponseDto"

Ofcourse I am able to fix this with readable: false. Though that feels a bit weird... And does not align with the Dto structured way of thinking... Is there a different option to manage this?