Since we're on the topic of design, we need to discuss versioning, because you remember this is essentially a data access layer, so any change that we make could potentially break a client, and we don't want to do that. So any new feature, any new changes that we need to make, need to be done under a different version. Now you might think, I don't need to version my API, this is a simple API that I'm writing for myself, no one else. Yeah, you still need to, because how many times have you written something, then you came back to it later and wished, man, I wish I would have done that. It's the story of my life. So just think about versioning. It doesn't take a lot of time. In fact, it's very easy. So just always include versioning, and you will always thank yourself for it later.

think about versioning. It doesn't take a lot of time. In fact, it's very easy. So just always include versioning, and you will always thank yourself for it later. So we need to think about how we want to include versioning here, and the easiest and most straightforward thing to do is just to include it in the URL. For one, that makes it easy for clients, because they know exactly what version that they're using, but for us, it also makes it easy, because we can route requests to a specific controller based upon that URL. So if we have v2 for tickets, that means that we can route that request to our version 2 TicketController, because yes, we will have different versions of controllers. So this just makes the most straightforward thing to do. We could use headers or something else, but that just

yes, we will have different versions of controllers. So this just makes the most straightforward thing to do. We could use headers or something else, but that just over complicates things, and life is complicated enough. Don't complicate your software. So now the question becomes, how do we implement this? Well, we could use modules, and in fact, we have a course here at LaraCasts by Mateus called Modular Laravel. It's a very good, I highly recommend it. There's also a little bit of setup involved, and while that might be a great approach, that's not what we are going to do. We are just going to modify the default structure so that inside of app and Http, like controllers, so what we will do is have a new folder, we'll call it API, so that all of our API related controllers will be

that inside of app and Http, like controllers, so what we will do is have a new folder, we'll call it API, so that all of our API related controllers will be inside of the API folder, just so that we could separate that from any other controller that would handle our typical web application, and then inside of there we would have a folder for our different versions. So here we would have v1, and then v2, and v3, and so on, and then we will have our controllers for those different versions there. We'll do the same type of thing for any other type of class that we need, like requests, or resources, or things like that. So let's create a controller. Let's go to the command line, php artisan make:controller, it already knows what I want to do. So whenever we create the

create a controller. Let's go to the command line, php artisan make:controller, it already knows what I want to do. So whenever we create the controller, we just need to specify the folder structure that we want. So api/v1/TicketController, and that's going to get us a TicketController with the folder structure that we want. But let's also use the --resource flag, that way it will scaffold all of the methods that we will need, because you know we need the index method, we need the store method, we need the update, delete, there's several methods that we need. It would be useful just to have those automatically there, and we could also go ahead and tell it to not only create the requests that we would want to use, but also type in them.

just to have those automatically there, and we could also go ahead and tell it to not only create the requests that we would want to use, but also type in them inside of our controller. So this will create a TicketsController. Let's go to controllers, API, v1, and then TicketController, and we can see that we have the show method is being type hint with Ticket. If we look at the store method, it is being type hinted with the StoreTicketRequest. Now if we look at the requests folder, it's going to be a little bit different because it created those requests directly inside of the requests folder, and instead I would want to do the same thing for the requests that we did with the controllers, so that we would have requests, and then API, and then v1, and then we would have our

to do the same thing for the requests that we did with the controllers, so that we would have requests, and then API, and then v1, and then we would have our requests. That way we just keep things structured the same, and we aren't mixing and matching our request objects. We do need to change our namespace here, so this is API v1. We need to make the same change inside of updateTicket, but then we also need to make that change inside of our controller. So let's go back to the TicketsController, and let's change this use statement, and that should get that fixed up. So what we can do inside of the index method, we will simply return, we will use our ticket model, and for right now we'll just return all of our tickets. We won't worry about storing or anything else like that, at least for

return, we will use our Ticket model, and for right now we'll just return all of our tickets. We won't worry about storing or anything else like that, at least for right now, and that should get us going, although we need to set up the route for this. Now we could go inside of api.php, and we could add our routes here, and in fact we have that tickets route from the previous episode, but I don't want to do that, because then we would end up with a file that has all of our routes for all of our different versions, and that can get very unruly very quickly. So instead what I want to do is break it out by files, so that the api.php file will be our base API routes. So things that don't need versioning like login and register, you know, those could be defined inside of api.php, but then we would have an

our base API routes. So things that don't need versioning like login and register, you know, those could be defined inside of api.php, but then we would have an api_v1, and this is where we would put all of our routes for our version 1. So we could have our route, and then we could say resource tickets, and then we would use the TicketController class. Now we don't really want to use resource here, because this is going to set up routes for the URLs that we don't need. Like for example, this would set up an api_v1 tickets create, and we don't need that URL because the create endpoint would be for showing the form for creating a ticket. We don't have a form to show, so instead of using resource, we can use apiResource, and this is going to set up the routes for

for creating a ticket. We don't have a form to show, so instead of using resource, we can use ApiResource, and this is going to set up the routes for only the things that we need. So this is going to give us the ability for tickets, for getting the ID, and for storing tickets, but it's not going to set up routes for the unnecessary things for an API, which would be for showing forms. So this create method, instead of our TicketsController, we can just get rid of because we don't need it. The same is true for the edit method, so we can get rid of that, and we'll leave everything else there. But we also have to tell our application to now load our version 1 API routes, and we can do that inside of our RouteServiceProvider, that is inside of the app folder, providers, route

application to now load our version 1 API routes, and we can do that inside of our RouteServiceProvider, that is inside of the app folder, Providers, RouteServiceProvider. And inside of the boot method, we're going to see where the routes are being set up with this closure. We can see that the API middleware with the prefix of API is being mapped to routes/api.php. We can essentially copy this, and we just need to make a couple of changes so that the prefix would be API/v1, and that would map to the api_v1.php file, so that now all of the routes that we define inside of our version 1 route file, we don't have to say v1/ and then tickets. It's automatically going to be done because the prefix has been set that way. So if

version 1 route file, we don't have to say v1 slash and then tickets. It's automatically going to be done because the prefix has been set that way. So if we go to Postman, let's create a new request. Although, let's create a new collection first, and let's rename it to tickets, and then we will add a request here. We'll call this getTickets, and we will make a request for our localhost:8000/api/v1/tickets, and whenever we send that request, we should get a response back that shows all of our tickets, and it does. And so now that we are done designing our API, and we have data to work with, we need to focus on authentication and authorization, which we will start in the next episode.

authentication and authorization, which we will start in the next episode.