API Platform 3 Parte 3: Recursos personalizados
About this course
Gracias a la parte 1 y parte 2, ya hemos creado una API muy potente, con seguridad, campos personalizados y muchas más cosas. En este curso, llevaremos las cosas aún más lejos:
- Proveedores de estado y campos personalizados "adecuados"
- Ejecuta código personalizado en un cambio de "estado" (e.g. publicación)
[ApiResource] Clases DTO personalizadas (sin entidad)
- El nuevo atajo
stateOptionspara DTO's - DTO's y proveedores de estado (
make:state-provider) - Procesadores de estado con DTO's
- Transformación de datos con
symfonycasts/micro-mapper IGNORED_ATTRIBUTESsecurityy otros trucos para evitar los grupos de serialización- Objetos embebidos (incluidos los objetos que no son ApiResource)
- Paginación para recursos DTO
Woh. Si pensabas que antes eras peligroso con API Platform, sólo espera...
Next courses in the APIs: API Platform 3 section of the APIs Track!
17 Comments
weaverryan
SFCASTS
Peter-P
4 months ago
Hey @Peter-P!
I'm hoping to do an episode 4 at some point, which will include filters. No timeline however! Until then, we do talk about custom filters in the API Platform v2 version of this tutorial - https://symfonycasts.com/screencast/api-platform2-extending - as far as I know, not so much has changed in this area.
I don't see how they work with custom resources. Is there an easy way to make it work?
But to answer this, yes, when you have a custom resource, you probably need to create custom filters. If you're using our stateOptions + entityClass trick, then you can reuse the normal "entity" filters, which we showed.
If you have any questions along the way, I'd be happy to do my best to answer them.
Cheers!
MolloKhan
SFCASTS
Evgeny
5 months ago
edited
Thank you for your suggestion @Evgeny we love to know what other topics you'd like to learn, and we consider them when choosing our next tutorial.
Cheers!
Alessandro-M
8 months ago
Yes!!
This is the course I've been waiting.
Looking forward to it! :)
fGuix
9 days ago
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 ;)
MolloKhan
SFCASTS
fGuix
9 days ago
edited
Hey @fGuix
That's a good observation. The validator will stop if the DragonTreasureApi object has no owner (a new object has been created), or if the owner changed. But, as you said, there's a tiny issue with this code, it won't check all objects. What I can say is Ryan assumed that all the modified objects belong to the same owner. It can be seen as a bug or not but it can be easily fixed by changing the return statement by continue
Cheers!
sadikoff
SFCASTS
fGuix
9 days ago
Hello @fGuix,
Nice catch, the case looks legit. The best thing to bypass this issue I think will be to change return; to continue;. We will discuss internally how to fix the course properly.
Cheers!
Jeremy
2 months ago
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.
MolloKhan
SFCASTS
Jeremy
2 months ago
edited
Hey @Jeremy
Yea, I agree, it feels like a lot to do if you want to rely on DTOs. I hope ApiPlatform will add better support to DTOs in the future
Cheers!
Peter-Hoehne
2 months ago
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
weaverryan
SFCASTS
Peter-Hoehne
2 months ago
Hey @Peter-Hoehne!
Yea, I think understand the issue and I've had this conversation in the comments on this tutorial a few times (I wish I could find those!).
The answer is (c). Others have suggested it, and I agree. It also removes the need to manually call $data->id = $entity->getId(); to set the entity id back onto the DTO. The micro mapper will take care of that.
So yea, go for C! There could be a small performance impact, but I bet it's small, and it will only happen on those write operations anway.
Cheers!
MMilev
4 months ago
edited
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"
}
}
I have found the culprit. I use the suggested EntityClassDtoStateProcessor but it does not populate the ID field for all the embedded objects, thus generateIriFromResource throws an exception. In the code bellow the commented line actually makes it work for the discussed case.
EntityClassDtoStateProcessor#process
...
$this->persistProcessor->process($entity, $operation, $uriVariables, $context);
$data->id = $entity->getId();
// $data->profile->id = $entity->getProfile()->getId();
return $data;
Hey @MMilev!
Ah yea, that makes sense. Some people, which I think makes sense, have been using the micromapper after calling $this->persistProcessor->process() to map the $entity back into the DTO. Because the $entity (and in your case the Profile) now have ids, this maps the ids back to the DTO's.
Cheers!
MMilev
weaverryan
4 months ago
Hello, thank you for your answer :) I will try that :)
Best regards :)
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?