Laravel API Resources for Same Model: Re-Use or Create New?
Vložit
- čas přidán 19. 06. 2022
- If you want to use Eloquent API Resources for multiple Laravel API endpoints, should you use the same resource, or create a different one? Let's discuss.
My courses related to APIs:
- React.js + Laravel: SPA CRUD with Auth laraveldaily.teachable.com/p/...
- Vue.js 3 + Laravel 9 SPA: CRUD with Auth laraveldaily.teachable.com/p/...
- Flutter Mobile App with Laravel API laraveldaily.teachable.com/p/...
- How to Create Laravel API laraveldaily.teachable.com/p/...
- - - - -
Support the channel by checking out my products:
- My Laravel courses membership: laraveldaily.teachable.com/p/...
- Laravel QuickAdminPanel: bit.ly/quickadminpanel
- Livewire Kit Components: livewirekit.com
- - - - -
Other places to follow:
- My weekly Laravel newsletter: bit.ly/laravel-newsletter
- My personal Twitter: / povilaskorop - Jak na to + styl
I think that resources are like form requests. At the beginning you try to use one single item for everything, then you understand that creating a new file costs you nothing.
With conditional resource like when($request->routeIs(`list`)) you may somehow manage to use same resource class for all endpoints
Again, thanks to share this specific topic ! It gave me such a headache when i tryed to merge the small one into the biggest. I never successed of course. I hate to repeat my self but here ... i guess we have to !
I'd recommend not naming a resource a plural (categories) but sticking the convention of using a singular (category). The resource that is serialised in the toArray method is always a singular item. Also, it's surprising to have some resources in singular and others in plural. I suggest resource names of: CategorySummaryResource and CategoryDetailResource. But to each their own.
I'd never recommend to use `MyResource::collection()` method, because it returns the immutable AnonymusResourceCollection class. A resource class should have only one purpose: representing a single model (e.g. a post in the show, store and update methods). If you want to create a list of them, then create a separate resource collection class which collects the resource class (or a separate resource class for list elements if needed).
Separating resources and resource collections for different purposes are cost almost nothing but gives you more control.
Hello sir, excuse me, can you have some link to the example ? Thanks for the tip
I think it always depends on a specific scenario, sometimes it makes sense to reuse the resource (if for example I have a resource with 10+ fields and need to optionally include/exclude one or two of them, this way it is easier to maintain the resource later in case if the model changes) and in other situations it makes sense to create separate resources when the difference is significant. I've used both approaches.
I usually preffer to leave the Controller/Query with the responsability to get only the data I want to display, and the Resource as much dummy as I can, using $this->when() to display stuff and not placing too much logic on them, at max giving some styling to the output, in that way I minimize the number of resources that grow like weed on big projects and have a more flexible way to use them.
But of course, it's not a golden rule, when you realize that you need different keys or value formatting, it's a call for a new resource.
u can override the constructor to use same resources class for different purpose
It somehow convinced me to adopt this new idea
We have access to $request in CategoryResource file, so cant we merge additional input using
$request->merge(['descriptionRequired' => true]); // before returning CategoryResource
and then
$this->mergeWhen($request->descriptionRequired, [
'description' => $this->description
]); // in CateogoryResource file
to merge description field when ever required
Good evening, a question:
How can I send data from a form (customer_name, country, state, city, telephone and others) to a microservice and that it can insert the data or query it, taking into account that I have sent several parameters.
Regards :)
Yes I agree with this. Every request usually have different data needed.
But I just wondering, what should we do to keep the keys same and consistent?
Maybe in a team, A use 'desc' key but B use 'description' key.
Not sure if I need make constant variable in Traits for each keys? Or maybe a new class?
Good catch, with different classes it's hard to keep consistency, I guess it's just a matter of communication in a team.
I literally had the same issue a week ago and also opted for separate resources.
How about Complex nested Resources with relationships?
I have had this issue before, my personal solution was to make a base class that holds the share attributes like id, name, and created_at so that I am sure it will not be touched, that was very important in my scenario because in some cases I need to send some attr in all APIs that have this resource, other attributes that exist in some APIs and not in another I make an isolated class for each API I need, with this solution I mixed-use part of code and isolated business logic, and the important thing i have very clean resources without any conditions
Hello Povilas Korop,
Instead of creating different resources for the different endpoints for same modal, I prefer to use a switch case based on route name in the same resources for all endpoints. Maybe it is better if we compare it with different resources for the same modal.
That's another way of doing it, yes.
this is interesting. will try this one out. thanks for the idea!
I think one resourse best way but inside resourse class use match or switch method to use the correct route…
Yes, I recently came to the same conclusion. On one's own)
I think we can use one resource with "select" a params on the query and use in resource when function ..
return [
'id' => $this->when($this->id, function () {
return $this->id;
}),
]
How do you solve situation, when you change your model and you need to update all Resources?
I update all resources, then. It's a rare occasion and I don't remember creating more than 3 resources per model.
Thank you a lot 💙
Is your React course just normal React, or NextJS?
I'm looking for SSR but with a Laravel API and Auth. I was going to start with the Laravel Breeze and the NextJS template that is recommended in the docs.
Normal react, without SSR. That's a course for React beginners, SSR or frameworks are another new level.
What about relations between api resources, so if i want to use comments resource inside post resource and so on, it can be endless to create resource for each request! I think it is better to work arround with some conditions even to let the full description if will not cost alot for memory usage as we always use pagination for such senarios or getting some fixed number of records. So creating a new resource for each route will cost us more, as we are not reusing the code, any change in one table should be reflected in all resources.
Well, I don't think you would have THAT many resources so you wouldn't remember them, especially if they are in the same folder. But I see your point, if you have a chance of a lot of future changes, then perhaps a reusable structure with some conditions is better, for your case.
Also maybe use the helper request inside categories resources and make some conditions? And then reuse original CategoryResource ?
Yes I agree with you
That's another way of doing it. But somehow it feels to me like a "code smell" that response has access to the request. Controller should cover the parameters processing.
I don't use api resources because it will have am extrea query when performing the controller actions.
Personally, I prefer inlining instead of using Resources. That way, I can see in the controller what is returned. Using Resources has always seemed like chasing the "slim controller" idea by sweeping the code under a rug (Resources, Actions, Services) without really simplifying anything.
There are some nice things you can do with Resources however, like conditionally returning columns using then when() method or rendering related models as their own resources. In the absence of that kind of logic, I don't think Resources are needed.
Can you make a tutorial video for users, roles and permissions using spatie? I'm having a problem with update role and it throws an error 'this name is already taken'. Thank you in advance
I don't think you need a tutorial video, there are a lot of them on the internet. You need to solve specifically your problem, so you need someone's help to debug it. Unfortunately, I don't have enough free time, to do that. Put your problem on Laracasts forum, for example.
@@LaravelDaily Thank you for your suggestions
So it seems that NAME coulmn of roles table is unique and could you share your code of updating role, I would be glad to help you. Thanks
👍👍👍
how do you handle documentation for this? i find it very tedious to manage 4-5 different resources for the same model in the docs
Why/how do you document the resources? You should document API endpoints, not resources, at least that's what I tend to do.
@@LaravelDaily for reusability -- i make schema in openapi and (try) to reuse them as much as possible -- descriptions of the exact same named property are a nightmare to update in more than one place
Hmm, I haven't worked with openapi for a long time so it may make sense in your case. I document just the endpoints for the API with Scribe, it doesn't care about API resources inside.
When Im building API, I never use Resources. I just return models as they are. (of course hiding sensitive data). Is this bad practise?
No, whatever works for you, if you don't need any transformations from the model
the course link says "This product is not avalable"
I've moved my courses in 2022 to my own platform, see laraveldaily.com/courses
agreed with more readability, don't wrap too much layer.
categoriesResources::make() Vs new categoriesResources() ?
Personal preference
Hello sir, Why my eager loading is not working? It create multiple queries.
Relation: prnt.sc/JUdR11Wh1oMd
Query : prnt.sc/77LNQUCsNQvb
Result : prnt.sc/t0HoBVm3fOrU
Also, How can I avoid spatie permission queries on every page. I have to check the permission.
Visual Details : prnt.sc/8riyzAY7ujO5
I think it's an expected behavior that every page checks the permission, that's what it's supposed to do, no?
With eager loading, have you tried leaving just with('orders.items') alone?
And actually, I think it DOES the eager loading, one query per relationship.
@@LaravelDaily yes, Its run one query per relationship. Is it possible to run only one query?
@@bmtamim7818 you cant with built-in Eloquent ORM behavior.
@@user-fi1uh8ct2j Got it..thanks
@@LaravelDaily Thanks a lot..sir❤️