Custom Resource Item Provider
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribeLet's try to get a single item. I'll change the date, hit "Execute", and... 200 status code. Hold your horses... this is returning a collection: the exact same data as our collection endpoint!
Collection vs Item Operations
Ok, each operation can have its own provider. But when we put provider directly under #[ApiResource], this becomes the provider for every operation. That's peachy... given you don't forget that some operations fetch a collection of resources while other fetch a single item.
Inside our provider, the $operation helps us know the difference. dd() that...
| // ... lines 1 - 9 | |
| class DailyQuestStateProvider implements ProviderInterface | |
| { | |
| public function provide(Operation $operation, array $uriVariables = [], array $context = []): object|array|null | |
| { | |
| dd($operation); | |
| // ... line 15 | |
| } | |
| // ... lines 17 - 32 | |
| } |
Then, over here, copy the URL, paste it in a new tab and add .jsonld to the end. There we go! This is a Get operation. If we try to fetch the collection, it's GetCollection.
Back in the provider, if ($operation instanceof CollectionOperationInterface), return $this->createQuests().
| // ... lines 1 - 4 | |
| use ApiPlatform\Metadata\CollectionOperationInterface; | |
| // ... lines 6 - 10 | |
| class DailyQuestStateProvider implements ProviderInterface | |
| { | |
| public function provide(Operation $operation, array $uriVariables = [], array $context = []): object|array|null | |
| { | |
| if ($operation instanceof CollectionOperationInterface) { | |
| return $this->createQuests(); | |
| } | |
| // ... lines 18 - 19 | |
| } | |
| // ... lines 21 - 36 | |
| } |
Below, we know this is an "item" operation.
URI Variables
So this does keep the collection operation working. Now, we need a way to extract the date string from the URL so we can find the one quest that matches. How can we get that? dd($uriVariables).
| // ... lines 1 - 12 | |
| public function provide(Operation $operation, array $uriVariables = [], array $context = []): object|array|null | |
| { | |
| // ... lines 15 - 18 | |
| dd($uriVariables); | |
| } | |
| // ... lines 21 - 38 |
When we refresh... behold: there's a dayString inside! Notice that, in DailyQuest, we never configure what the URL should look like. You can do that, but by default, API Platform automatically figures out what the route and URL should look like. Run:
php bin/console debug:router
For the item endpoints, it's /api/quests/{dayString}: the dayString is a wildcard in the route. In the provider, $uriVariables will contain every variable part of the URI - so dayString in our case. That makes us dangerous.
Returning a Single Items
Down here, we need to return a single DailyQuest or null. Say $quests = $this->createQuests(), then return $quests[$uriVariables['dayString']] or null if it's not set.
| // ... lines 1 - 12 | |
| public function provide(Operation $operation, array $uriVariables = [], array $context = []): object|array|null | |
| { | |
| // ... lines 15 - 18 | |
| $quests = $this->createQuests(); | |
| return $quests[$uriVariables['dayString']] ?? null; | |
| } | |
| // ... lines 23 - 40 |
Remember: this works because the array uses dayString for each key. In a real app, we would want to do this more efficiently: it doesn't make sense to load every quest... just to return one. But for our test app, this will work fine.
Ok, try that endpoint. Got it! One result. And if we try a random date that doesn't exist... like "2013"... we get a 404. API Platform sees that we returned null and it handled the 404 for us.
We are now the proud parents of a fully functional state provider! Though we'll talk about this more soon - including topics like pagination. But next: let's shift our focus to creating a state processor for our custom resource.
4 Comments
Hi,
I'm working on an api with a State Provider and Voter, I'm finding that the provider is invoked before the voter. This leads to some odd results, 404 instead of 401. In the API Platform doc's I can see that providers are invoked by ReadListener event, and debugging my projects kernel.request (bin/console debug:event-dispatcher kernel.request) I can see DenyAccessListener is next in the ordering.
Is there a way I invoked my Voter before the State Provider?
Thanks
Hey @Joe-L!
Hmm. Assuming you're talking about a voter used in a context like this:
Then you're totally right... and the problem is that the provider must be invoked first so that the
objectis available to be passed to the voter.You said that you're hitting a 404 instead of a 401? Is that because your provider contains the logic to filter down and only return the correct record(s) based on your security rules? If so, for the item operation, if you need a 401, I would stop doing that, allow the object to be found and then let your voter do its work.
But maybe you have some more complex requirements. Let me know!
Cheers!
Hi Ryan,
I have a provider to retrieve data from an external source (in this case S3), and want to add security to limit who has access to this endpoint.
If a request is made with a bad id and by a user who doesn't meet the requirements in the voter, then a 404 is return. In my opinion this would suggest the user has access but has provided the wrong id. Is there a different solution I should be using when I want to limit the API access regardless of the content in the response? In this case we're potentially making unnecessary requests to our external source, we'd like to mitigate this as much as possible.
Many thanks
Hey @Joe-L!
Sorry for the slow reply - life hit :)
I see - the provider does its job and THEN if successful the voter is called. There's really nothing wrong with adding some security code into the provider itself. If you want to trigger a 403, I think you can just throw an
AccessDeniedExceptionand that'll throw you into the normal 403 flow.Let me know if that helps!
Cheers!
"Houston: no signs of life"
Start the conversation!