Input DTO Class

Hi Don!

Yea... that does some complex. I don't have any direct experience with non-entity classes and relating them. However, I "think" that, on an API Platform level, all API Platform cares about is that class A contains an instance of class B on a property: it does not need to be (and shouldn't be) using a ManyToOne attribute from Doctrine. So, for example:

#[ApiResource]
class A
{
    public string $name;

    public B $b;
}

And, of course, B is also an #[ApiResource]. With just this setup, I believe you should be able to do something like this:

POST /api/a

{
    "name": "foo",
    "b": "/api/b/5"
}

I "think" (but I am doing some guessing), that API Plaform will see that the b field should be an instance of B and that B is an #[ApiResource] and so it will then use the IRI (/api/b/5) to "find" the B object with id 5 using your DataProvider for B. It would then call ->setB($b) on class A. I'm guessing you also have some sort of private int $bId property on A where you store the id. So, to handle setting that, you could do something like:

// A.php

public function setB(B $b)
{
    $this->b = $b;
    $this->bId = $b->getId();
}

Additionally, IF you want to get fancy, you could use a post-hydration (I think this is the hook you want) listener on Doctrine that could read the bId field and use the API to find the B object and set it onto the A class every time you query for A. The downside is that you'll be hitting the API every time you query for an A - so it's up to you :).

Let me know if that helps!

Ryan! Hi there!,
Thank you so much for your thorough reply!. Yes! :) for the POSTing part I was half way on doing your proposal, but very uncertain if I was on the right path, the best or the only one. (like most of the time on API Platform :P).
So, POST worked perfect and as expected.

Now for the GET part, post-hydration was the exact word that I was looking for that. I used a Doctrine Listener on PostLoad and worked!, of course I endup duplicating part of the code that lives in BDataProvider::getItem() so next step would be re organize (try) the code to not repeat myself.
I'd like to ask you couple of followup questions:

1. Is Doctrine Listener the only solution or is another way of doing the post-hydration?
2. Is there a way of calling the DataProvider::getItem() to the job of post hydration?
3. Thinking only about consistency, is it ok if GETing the resource for A only shows B_id instead of B IRI?.

Thanks again, and keep up the great job you are doing with these tutorials, I'm very happy that you are addressing more advanced topics, that really helps on getting us to the next level.

Hi Don!

Yay! I'm really happy to hear about all your success - and thanks for following up to tell me!

1. Is Doctrine Listener the only solution or is another way of doing the post-hydration?

You could also do it manually in your app code. For API Platform, that would mean doing it in the "data provider". For example, you could decorate the "Doctrine" data provider - https://symfonycasts.com/screencast/api-platform-extending/decorate-provider - you would call the Doctrine data provider so it can do its normal logic for fetching the A entity. Then you would manually grab the A object, read the bId off of it, fetch over the API for B, then set it onto A. That is, I think a perfectly acceptable alternative to the Doctrine Listener.

1. Is there a way of calling the DataProvider::getItem() to the job of post hydration?

I think I answered this above - but let me know :). Yes, the idea is that YOU need to have a custom data provider for A. But of course, you don't want to do ALL of the work - so you decorate the Doctrine data provider so it can do most of the work... then you do the little tweak with B after.

1. Thinking only about consistency, is it ok if GETing the resource for A only shows B_id instead of B IRI?.

It depends on who is using your API. If only YOU are using it... then who cares! :) But, it IS a bit weird that all of your other relations would use an IRI, and it would be different here.

However, you did give me an idea. In theory, if you KNOW that you will only return the IRI - and not the actual data - in the custom data provider for A that we're discussing, instead of fetching B from the external API, you could create a fake, empty B object that ONLY has its id set (which you already have). In theory, the serializer would use that to create the IRI... never caring that the object is otherwise empty.

Cheers!

Hi Ryan!.. awesome!..
I have learned a lot in this couple of posts.. Thanks a lot for taking the time and give such a complete answers, they were very clarifying.
So, these are the results:

• Begining with your last paragraph, don't konw why I did not think about that!, I'm doing exactly the same when a B resource is created so Api Platform will return the IRI for the newly created resource. (that works!)

• Using that idea, placed in the DoctrineListener and worked beatifully.
  Then moved on creating ADataProvider and test the same thing and also worked, of course.
  Lastly, in case B details needed to be shown, inject BDataProvider in ADataProvider::constructor() and instead of doing a new B(), simple call to BDataProvider::getItem() and worked extremely well.

Now, let's go celebrate (as you would say).

Cheers!

Woohoo! This is a really cool situation - it's awesome to hear that it's now all working nicely! Yup, celebration time :D

Hey Gianluca!

Sorry for the slow reply - the team left this tougher question for me :). Hmm... I'm not really sure what the "best" way to handle this would be. So yes, I'd probably try this with a DTO. In theory, if you create a DTO that looks like the JSON, then the JSON will deserializer into the DTO, then you can transform it back into a Book. Should you create a custom operation? That depends on whether you need to keep the "original" POST action or if having this new POST action is the only you need. If it's the only you need, then skip the custom operation and make the original POST operation use your DTO. If you DO need a custom operation... I'm not sure whether you would need a custom controller or not... it might be enough to create the custom operation and configure it with the DTO (and no controller is needed).

I'm going some guessing here about the way to handle things, but let me know if this helps or if you found a nice solution :).

Cheers!