Okay. The way that we write web applications has drastically changed, and really it started with Angular. Once Angular came on the scene, the idea of a single-page application became a reality. We could kind of get away with it before, but Angular is really what made it possible. And then, of course, React and Vue came on, and, well, it's just how we write modern web applications. The client does a lot of the heavy lifting. In fact, it does a lot of the work that the server used to do. It generates the markup that's rendered within the browser, and the server is, well, really it's a glorified data access layer. That might be a little unfair, but really that's all it is. So, of course, web applications still need a server side, but it's a little bit different. We need to write an API, which is a different approach from writing a typical server.

that's all it is. So, of course, web applications still need a server side, but it's a little bit different. We need to write an API, which is a different approach from writing a typical server application. So, let's learn how to do that. Now, we can start an API in a variety of ways. We could reach for Laravel and create a Laravel project, or we could create a Lumen project. But really, Lumen is, well, it's very well suited for really small micro APIs. If you need anything beyond really simple stuff, you will want to reach for Laravel. So, let's create a new Laravel project. Let's call it Tickets, please. And, of course, we are going to be prompted with how we want to start. Do we want no starter kit? Do we want to use Breeze or Jetstream? Now, we could choose any one of these options, and it's going to be fine. Jetstream is going to give us a lot of out of the box because it has Sanctum already set up and ready to go. The same is true for Breeze. And,

one of these options, and it's going to be fine. Jetstream is going to give us a lot of out of the box because it has Sanctum already set up and ready to go. The same is true for Breeze. And, in a real project, we would probably reach for one of those options because, well, it just saves us time. However, our goal here isn't to write a real application. We want to learn how this stuff is going to work. So, let's start with none, and we're going to do everything from scratch. For our testing framework, let's choose PEST. And, yes, I want to initialize the Git repository. For our database, let's choose MySQL. And then, let's write our first route. And we will do so by going to the api.php file inside of our routes folder. And there's already going to be a route in here. We will see that it is for the user endpoint. We don't need to worry about that right now. We just want a route that's going to handle a GET request for the root of our API. And let's

We will see that it is for the user endpoint. We don't need to worry about that right now. We just want a route that's going to handle a GET request for the root of our API. And let's just return a response that is going to have some JSON. Because when it comes to building an API, JSON is the de facto standard for our data format. There's nothing that says that you can provide data in another format. It's just that most clients expect JSON. So, let's have a structure that has a message. And then, we'll just say, hello world. Or let's do hello API. Let's make this return the status code of 200 for okay. And then, let's test it. Be sure that your project is running. And we will go to /api. Because when it comes to an API, the URL begins with api. We can change that. But the convention is to stick with the api prefix. So, whenever we make a request, we will see that we get a JSON response. The message is hello API. Now, of course, most of

can change that. But the convention is to stick with the API prefix. So, whenever we make a request, we will see that we get a JSON response. The message is hello API. Now, of course, most of the time, we want to handle these kinds of requests using a controller. So, instead of using this route, let's create a controller. In fact, let's create an AuthController. Because we will want to provide the ability for users to sign in, sign out, and register accounts through the API. So, let's make a controller. Let's call it AuthController. And let's start with a login method. Now, we're not going to actually log in. But we will essentially do the same thing that we did for our beginning route. We will return a JSON response so that we can see that it's working as it should. So, let's have a public method called login. We will paste in that code. But let's change this. Let's say hello login. And we, of course,

we can see that it's working as it should. So, let's have a public method called login. We will paste in that code. But let's change this. Let's say hello login. And we, of course, need to set up this route. The URL would be simply /login. And we will specify the AuthController and the login method. Now, of course, the URL that we need to hit is going to change. But it is still prefixed with API. Let's hit API/login. And we, of course, see hello login. But this is going to be a common pattern to where we, of course, want to return JSON. But we also want to supply some kind of status code to go with it. So, really, it would make more sense to have a trait that we could use inside of our controllers. So, inside of the app folder, let's create a new folder called traits. And inside of traits, let's create a new file we will call APIResponses. And the idea here is we'll have some helper functions that will make

folder, let's create a new folder called traits. And inside of traits, let's create a new file we will call ApiResponses.php. And the idea here is we'll have some helper functions that will make it easy to return responses like an okay response for a status 200. So, we'll use the namespace of App\Traits. We'll have the trait of ApiResponses. And let's start with a protected function which we will call success. So, this is something that we would call anytime that the request is successful. And we will have a default of a status code of 200. Because when it comes to successful requests, we can have a 200. We could have a 304. There are a lot of status codes that could be considered successful. So, we'll just call this success. We will be able to supply a status code. And then we will simply want to return a JSON response so that we'll have our message which we will set to what was provided to the function. Then we will have a status that

supply a statusCode. And then we will simply want to return a JSON response so that we'll have our message which we will set to what was provided to the function. Then we will have a status that will be set to the statusCode. And of course, we'll pass the statusCode as the second argument to the JSON method. And that's going to be fine. But I want to make this as easy as possible as we are using these functions. So, I want another one called simply okay that we can supply a message to. And it will call the success that we just wrote. We'll pass in the message. And the status will be 200. So, we can go back to AuthController. Let's use our new trait called APIResponses. And here we will simply return okay. And then helloLogin. That simplifies the code whenever we need to return some information to the client. And if we go and test this, and there we have our JSON structure. Now, of course, when it comes to developing and testing web APIs, we don't want

we need to return some information to the client. And if we go and test this, and there we have our JSON structure. Now, of course, when it comes to developing and testing web APIs, we don't want to use a browser. We want to use a more specialized tool. And we will look at one called Postman in the next lesson.