Subrecursos

Same small issue here.
I found this comment which sounds like the solution: https://github.com/api-platform/core/issues/5343#issuecomment-1400434403
I am not going to try this fix right now since this is just tutorial code so I am not sure if it works.

Remember that it's just an array you are passing to an Attribute Class.

As in, you could make a class somewhere that returns that array from a static function, and just reference to that function from inside the ApiResource block. That way you cut down on the amount of openapi stuff that's there, specially if it's just for touching up the documentation.

Another method is to decorate the api_platform.openapi.factory service.

In the __invoke() method of your decorator:

public function __invoke(array $context = []): OpenApi
{
    $openApi = ($this->decorated)($context);
    
    return $openApi;
}

Now your decorator does nothing, it's a no-op. But before the return $openApi call, you can modify the returned OpenApi object, to do as you wish. As in, fix descriptions, change names, add (more) example payloads, add whole operations, etc..

We use it to add custom endpoints from other bundles, or from the auth system, to add it to the OpenApi dump so it's a neat complete documentation, even filled with endpoints and resources that don't come from API platform.

Hey Joris-Mak,

Thanks for sharing this trick with others!

Cheers!

For anyone watching this, I am on api platform 4.3 and currently it is possible to do the following using the openapi parameter and a Parameter definition for the input

#[ApiResource(
    uriTemplate: '/treasures/{treasure_id}/owner.{_format}',
    operations: [new Get()],
    uriVariables: [
        'treasure_id' => new Link(
            fromProperty: 'owner',
            fromClass: DragonTreasure::class
        )
    ],
    openapi: new Operation(
        parameters: [
            new Parameter(
                name: 'treasure_id',
                in: 'path',
                description: 'The ID of the treasure',
                required: true,
            )
        ]
    ),
    normalizationContext: ['groups' => ['user:read']],
)]

Hey HiddeHiddema,

Thanks for sharing this tip with others!

Cheers!

Hey @Fireball!

Sorry for the very slow reply, life is getting in the way of my availability, and sometimes the team saves tough questions like this for me :).

I maybe don't know the answer either, but I do have some thoughts:

1) You won't like this answer, but if it were me, I would just POST to the non-subresource URL and save yourself the trouble

2) Buuuuuut, let's look deeper at POST /api/companies/1/employees. It looks like API Platform is trying to load the ONE Company, then getting surprised by the many results. The way you've structured the request makes sense to me, but you could also consider that what you're trying to do is "modify" the resource located at /api/companies/1/employees (modify the employees resource for the companies). Again, what you're doing makes sense to me, and maybe the solution is some simple tweak to your operations (though I don't see it). My point is, API Platform might want you to PATCH to /api/companies/1/employees and send the entire payload of all employees. Again, I realize that's not what you want, just trying to shine some possible reasons for why API Platform may not be playing nicely.

... or maybe there IS a simple solution and someone can tell us ;). That'd be the best.

Cheers!

Hi Ryan,

thank you for your answer! A few days later I found the solution but forgot I posed here the question.
There is a Provider in ApiPlatform that is marked as experimental and internal but solves exactly this problem.

It's this one: ApiPlatform\State\CreateProvider

I needed it for the following case:
I have an Entity that can have one or more related files which are modeled as Entities using VichUploader. Now while it would work, it would be a bit ugly to mix multipart/form-data with additional variables like the id of the related parent collection, so I wanted to pass the id via url like POST /api/post/12/files (my upload Endpoint). Files can't be edited, only created and deleted.
I created a copy of the CreateProvider in my own code in case it gets deleted in a future ApiPlatform update.

Hey Julien,

With ManyToMany you need to make this relationship first. We talk about this kind of relationship here: https://symfonycasts.com/screencast/doctrine-relations/many-to-many - but you may want to use this approach with OneToMany / ManyToOne to be able to save some extra fields on ManyToMany relationship, see: https://symfonycasts.com/screencast/doctrine-relations/complex-many-to-many

I hope that helps!

Cheers!

Hey @ulfgar-hammerschlag

That's unexpected :) - Perhaps it is due to how your entities relate to each other, but I can't know for certain. Anyways, thank you for sharing it!

Cheers!

Hey @Ammar!

I don't know the specifics about why the query is done this way, but yes, I believe in the latest version of API Platform you can override this - see https://github.com/api-platform/core/pull/5732

However, I've never done this - so I'm passing along the hint but I'm not sure if this is exactly what you want. But, I'd love to know if it helps!

Cheers!

Hey @Sebastian-K!

Hmm, interesting! Subresources are cool - and are MUCH nicer than in API Platform 2 (they were kind of a hacked addon the, but they're a first-class citizen now). And so, we can definitely use them. But we also may not need to.

Look at the URL: /project/123/task/456. That's gorgeous! But /task/456 is technically just as functional. If each Task has a relation to its Project, then from /task/456, we can look up the project from the Task and then see if the currently-authenticated user is an owner or not. Actually, even if I used subresources, I'd do the same thing: subresources are ultimately a bit of a "vanity" URL. At the end of the day, the object being loaded is Task with id 456.

So, for security, I'd create a custom voter (you're right that the default Role voter doesn't work when you need to decide permission based on some data - like I DO have permission to see Task 456, but not Task 123). Fortunately, we show this a bit in the next episode - https://symfonycasts.com/screencast/api-platform-security/access-control-voter - we first (in earlier chapters) show security using an expression, then we refactor it to a voter here. This strategy I think would work the same whether you decided to use a subresource or not. The /project/123 part of the URL just isn't that important (again, when you go to /project/123/task/456, it really just queries for Task 456 and THEN you run security checks. I DO think, though you could verify, that if a mischievous user changed the URL to /project/111/task/456, where Task DOES belong to Project 123, then it would result in a 404).

For "collection" resources, the strategy for filtering is slightly different - we talk about it here - https://symfonycasts.com/screencast/api-platform-security/query-extension

This part MAY differ slightly based on if you're using a subresource or not - but I'm not entirely sure:

A) If you do /tasks, then you can use a query extension like above to modify the query to only return tasks that are related to projects that the current user should have access to.

B) If you do /project/123/tasks, then API Platform will automatically only show tasks for project 123. But, what if the user doesn't have access to Project 123 at all? I'm actually not entirely sure how to handle this. The simplest solution is to, like with (A), create a query extension "to only return tasks that are related to projects that the current user should have access to". In that case, if the user doesn't have access to Project 123, the query would effectively be:

Find tasks WHERE project = 123 (this part is added by API Platform thanks to the subresource) AND (your custom part to filter to only projects the current user has access to).

So you'd filter to only tasks for projects the user should be able to see... and if that doesn't include project 123, it would result in null rows. The other way to do it would be to make /projects/123/tasks return a 404, but I'm not entirely sure how to do that :).

Let me know if this helps!

Cheers!

Thanks for the reply. Gave me new points to think about

Hey @urk!

Is there a reason why this is so twisted, purely from the grouping of the namespaces I find it so very strange.

I assume you're referring to how the sub-resources almost seem "backward" in the class they live in, right? Like the /users/{user_id}/treasures.{_format} is a "subresource under user"... and yet we put it into DragonTreasure.

I agree that it's a bit weird... but I think it would be weird the other way too. No perfect option :). The logic is that, because /users/{user_id}/treasures.{_format} will return "dragon treasures",. that's the class it should live on. It's almost like this is just a "vanity URL" / a different way to fetch dragon treasures. Of course, the downside is that the operations that we think of as "operations under /api/users" are split between multiple classes.

Anyway, I hope that gives some explanation at least!

Cheers!

Hey Ryan

Yes, you heard me correctly and I know what you mean.
It depends from which side you look at it. But it doesn't really have a technical reason. Thank you.

Thanks and cheers, Urs

Hey @Tac-Tacelosky!

Hmm, that's a good question! I've not done this yet, but... the getIriFromResource() method has a 3rd argument Operation $operation = null. But it looks a little tricky.

First, I think you need to give your operation a name - apparently you can add name: 'foo' inside an operation - like a new GetCollection(name: 'my_subresource_get_collection'). Then, to fetch that object, I think you can do this:

public function someAction(ResourceMetadataCollectionFactoryInterface $resourceMetadata, IriConverterInterface $iriConverter)
{
    $operation = $resourceMetadata->getOperation('my_subresource_get_collection');
    $url = iriConverter->getIriFromResource($yourObject, UrlGeneratorInterface::ABS_PATH, $operation);

Give that a try - I might not have things quite right - a bit of digging and guessing to find this - a new part of the code for me!

Cheers!

Hey Thomas,

yes, you're right, in this tutorial we don't talk about security, that's the topic of our next tutorial https://symfonycasts.com/screencast/api-platform3-security
it's going to be released soon :)

Cheers!

Wow - that's what I hoped!
Thank you for replying!