Every application has a user interface, and APIs are no different. In fact, our user interface is very commonly used. It's the URL. And I know that that sounds a little weird, but when you think about it, our users are developers. They are developing applications that use our API. So, they do so by sending requests to our URLs. So, that is our user interface, and it's very important that we take some time and design our user interface, or our URLs, because developers are going to be using it, and well, you know how developers can be. So, how do we go about doing this? Well, let's think about what a URL is. It stands for Universal Resource Locator. It's really nothing more than some text that identifies something specific on the internet. And the key word here is resource. But what is a resource? Well, it really depends upon the application. We are writing a support ticket system, so

something specific on the internet. And the key word here is resource. But what is a resource? Well, it really depends upon the application. We are writing a support ticket system, so our resources are related to the support tickets. So, we could have a resource called tickets. That would be the individual support tickets that we have. We're going to have users, because users need to be able to submit tickets. Those would be a resource. We could have some support contracts that we need to keep track of. So, those could be a resource as well. And the really cool thing about this is that resources pretty much map directly to Eloquent models. If you'll remember from the first episode, I said that web APIs are really nothing more than glorified data access layers. Well, this is why. Our resources are typically Eloquent models. So, all we need to do is create some models and then design URLs that people can use to access.

glorified data access layers. Well, this is why. Our resources are typically Eloquent models. So, all we need to do is create some models and then design URLs that people can use to access that data. So, let's think about this. We have a URL that is going to begin with API. So, anything after that would be accessing resources. So, if we wanted to access our tickets, then the next segment in the URL would be tickets. And if we wanted to access an individual ticket, we could have a segment after that that has the identifier for that ticket. And then from there, we could at least read all of the information about the ticket. If we wanted to edit, then we can add another segment to the URL. Or if we wanted to delete, we could do something like that. So, it would be tickets, the ticket ID, and then whatever it is that we wanted to do with that ticket. The same thing for users. So, users would give us a list of users. Viewing an individual

it would be tickets, the ticket ID, and then whatever it is that we wanted to do with that ticket. The same thing for users. So, users would give us a list of users. Viewing an individual user would be by using an ID as the next segment. And then we can edit or delete a user that way. So, that's going to be our approach. We just need to have some models. And we already have the User model. So, really all we need to do is use php artisan make:model Ticket. And let's have the model and the factory. We don't necessarily need the seeder there. So, with that model created, we can go to the migration. And then let's add some columns here. So, the first thing that we need is the foreignId for the user that submits the ticket. So, let's call foreignId. We'll pass in user_id. And we need this constrained. So, let's throw that in there as well. Then we just need some information about the ticket. So, let's have a string called title. And we'll have a text field

user id. And we need this constrained. So, let's throw that in there as well. Then we just need some information about the ticket. So, let's have a string called title. And we'll have a text field that will be the description. That way, the user can supply as much information as they need. And then finally, we will have a status. And, you know, we can approach status in a variety of different ways. But I typically go for just a single character. But sometimes a single character isn't enough. So, we're just going to make this a string. And we'll just call it status. Although for our purposes, I fully intend to have just a single character for the status. So, with that in place, we should be able to migrate our database. So, let's do that. We have our tables. So, now we just need to write our factory for our ticket. So, let's start with the user id. And here we are going to use the user factory. And then we will have the title, which

our tables. So, now we just need to write our factory for our Ticket. So, let's start with the userId. And here we are going to use the UserFactory. And then we will have the title, which we just need some words. We don't need anything really specific. So, let's use faker. We'll say that we'll have three words. But we need to pass true as the second argument. That way, it will return a string. Then we will have our description, which we will use faker once again. And in this case, let's use paragraph. And then finally, we will have our status. And we'll use faker once again. But then we need to think about what our status codes are going to be. We're going to use randomElement here. And then we just need to pass in an array of values. So, we will have A for active. Let's have C for completed. Let's have H for hold. And then let's have X for canceled. And I think that's going to be good. So, with the factory done, let's go to

we will have A for active. Let's have C for completed. Let's have H for hold. And then let's have X for canceled. And I think that's going to be good. So, with the factory done, let's go to our database/seeders and we want to create these 10 Users. And let's store them. Because then we can create our tickets like this. We will use our TicketFactory to create, let's say, 100 tickets. But then we will call recycle and then pass in our users. Now, if you're not familiar with recycle, this is basically going to create 100 tickets. And it is going to assign a random User out of this collection of users to that ticket. So, even though we are creating 100 tickets, we are not creating 100 Users. We are reusing the 10 Users that were created. But one User will be picked at random to assign to a ticket. Then we will create those tickets. So, we should be able to go to our command line php artisan db:seed. And hopefully that's going to work. It did. So,

picked at random to assign to a ticket. Then we will create those tickets. So, we should be able to go to our command line php artisan db:seed. And hopefully that's going to work. It did. So, now that we have some data, let's go back to our route. And we aren't going to flesh this out in this episode. We will start doing so in the next one. But let's say that we want our tickets route here. So, this is going to be a GET request because we are just getting the tickets. And let's not do anything fancy. Let's just return all of our tickets. That's not really something that we would really want to do. We would want to make this a subset of tickets. But for the sake of this, it's going to be fine. So, with that in place, let's go to Postman. Let's create a new request to where we request for localhost:8000/api/tickets. And we should see our list of tickets. We do. There is our JSON structure. And all 100 tickets should be here. And it looks like it is.

to where we request for localhost:8000 API tickets. And we should see our list of tickets. We do. There is our JSON structure. And all 100 tickets should be here. And it looks like it is. So, now that we have some data to work with, now that we know how we want our URLs to look, now we can talk about versioning, which we will do in the next episode.