API Versioning - How to make a Laravel CRUD API #6

[@KenuraTech]

Thanks. this video is usefull. still working after 4 years. very valuable.

[@danishmehmood6110]

this channel has the potential to become the best

[@QuentinWatt]

Thank you

[@oriksgaming8383]

The 3 people that disliked love plain PHP. Great tutorial!

[@QuentinWatt]

Thank you!

[@jmares79]

Thanks for the video! It really helped to figure out a versioning strategy. One question that arise is what would be the best way to version with different Form validation request resources. One idea is to have all separated by folder version but again, DRY comes to question it. Also, looking at the controllers code, they'll be pretty similar, so duplicating them seems like a "waste". Any ideas how can I separate by version, each of them with a different Form request validation class?

[@QuentinWatt]

I don't really like the concept of DRY. A lot of the time beginners take this way too seriously and try to make 1 function do far too much stuff and you land up with a Spaghetti function without a defined purpose. It's okay to have some repeated code here and there as long as it's for different resources that have different responsibilities. Those responsibilities often change and morph away from each other at the project grows and having some repeated code allows for that growth. You're probably not making simple changes between versions anyway. So the approach won't land up having much repetition.

[@Zorish373]

Thanks! This was super useful for the Rest API I'm doing, using all of these tricks! Wish we had more info on customizing input when creating users and such, like auto UUID and relationships with foreign id!

[@QuentinWatt]

It’s documented in Laravel’s docs if you don’t mind reading a bit.

[@christostsangaris4785]

Great video @Quentin! Just a question: Is there a way to tackle code duplication (keep things DRY) in case we have one PersonController returning views building up a page for the website and one Api\v1\PersonController returning JSON data for consuming API by a mobile app? Because the way I see it, separating the controllers is a good thing, but then again both controllers will have common code. Thanks!

[@QuentinWatt]

Use 2 controllers. Sometimes DRY can be taken too far. If the use cases are different, like in your case, with Web and API routes, then it's more than okay to have some duplication. What you could do if you really wanted, is create a Laravel use case, and use the same use case in both the web controller and the api controller.

[@adilismail3593]

Jwt or oauth for rest apis

[@Sortepr]

Great tutorial, learned a lot :)

[@QuentinWatt]

I'm so glad to hear that.

[@TyreeArt]

Is there some particular reason when you made the controller you put it under Api/v1, but the Resource was just v2 instead of Api/v2? Did you have to have the "Api" folder?

[@QuentinWatt]

It's possible I could have controllers for web routes, and controllers for API routes which can very often perform completely different tasks but might be named similar. So I like to have those separated with a folder so I know the difference. Resources will be used as resources, no matter if it's through the API or through a web route. So those don't need such division.

[@kendallarneaud]

@@QuentinWatt What it not be possible to use it still while keeping the OP's proposed structure? How tedious is it to keep track if it were being done to Models and Requests?

[@tareqabughoush9196]

Can I ask you why haven't you extended the v2 resources from v1? I mean, in some cases, the developer won't have to redo the whole apis, just some minor changes or updates, the copy pasting looks a bit messy. Just extend the original controller and override the functions with new updates or changes, sounds good?

[@QuentinWatt]

Personally I'd like them to be completely separated as we're simply returning an array, and I don't want to do extra digging to find keys I'd expect to see in v2 api resource. But how you do things is entirely up to you.

[@ShahZaib-dm1bh]

I have named routes, how should I handle routes? As we can't have routes with same name. "Error: Another route has already been assigned name". Please guide

[@QuentinWatt]

Give it another name 🙃

[@creative-commons-videos]

can i version whole app instead of just controller, like what about repository, models, etc these can also be changed depended on v1 and v2 changes, is there any way to version full app ? like laravel/v1/applaravel/v2/app, where app contains all the things like models, controllers, repositories etc

[@QuentinWatt]

😕 not sure what you're trying to ask. This is an API that can have different versions of returned data on different endpoints. It's always the same API, so that's not versioned, only the end points are. What it sounds like you're asking, is you multiple versions of an API? Which doesn't really have a very useful real world use case (that would be worth managing anyway), but in that case you set up 2 different Laravel Apps on separate subdomains.

[@kendallarneaud]

@@QuentinWatt What about version Middleware or Requests or even Models do you version Models and Middleware or do you cater for backward compatibilities?

[@rakeshkv1170]

what if we want do lots of logic inside this function, then how to use the resource, Can generate resource collection for each function

[@QuentinWatt]

You should try not to do a lot of logic in this function because it will slow down your API response time quite a bit. It'll be better to set up your Models and Relationships properly so you execute as little logic as possible. You can make use of Laravel "Use Cases" if needs be.

[@rakeshkv1170]

@@QuentinWattI have 2 DB connection to my model. I'll get all the data after that I have to extract data to visualize based on the region and date & time. It contains pretty big logic. May Be I have to create some private functions to keep the logic small.

[@Stoney_Eagle]

Man you realy make me work for it tho haha, while im at it why not add more rows to the table? I already have a laravel install that was build from front to back, now i want to do it right and start with the backend. The api route scheme i had was Route::group(['prefix' => '/v1', 'namespace' => 'Api\V1', 'as' => 'api.'], function () { Route::apiResource('/person', 'PersonController'); }); I just wrapped my version around it, Laravel is just that easy. Your tutorial has been a joy so far, i just hope you stop burning my eyes in future videos (Postman is the onlything white and it BURNZZZ 🤣🤣) Anyways i'll keep folowing the rest Thanks so far 😉

[@QuentinWatt]

hah don't be so quick to hate light themes :p

[@Stoney_Eagle]

@@QuentinWatt I don't hate white themes 😂😂 My eyes just hurt everytime you switch from a black to white screen.

[@kendallarneaud]

Why not "group" the version related files together? e.g. You have App\Http\Controller\v1 and App\Http\Resources\v1 ... Why not App\v1\Http\Controller\... and App\v2\Http\Resources\... App\v2\Models\.... ?

[@QuentinWatt]

I don't think you would really want to manage 2 different models. This would be completely unnecessary. Versioning the resource would be required for backwards compatibility which you can eventually phase out when you decide you have moved all your API consumers to the new version.

[@fernandogpz]

what about form requests?

[@QuentinWatt]

You can use these for forms. Form requests from an actual website will be done in a future tutorial series.

[@eloquent2200]

Thank you!

[@QuentinWatt]

You're welcome!

[@daviddeleon3411]

SIR THANK YOU :) :) :) :) :)

[@QuentinWatt]

It's a pleasure :)

[@pl_ro]

👍

[@QuentinWatt]

I appreciate that.

[@AniketSomwanshi-ll7mz]

thanks

[@QuentinWatt]

:) It's a pleasure.