[0:00] Hello guys, how to create APIs in
[0:02] Laravel. There's no specific
[0:04] documentation section for that. There's
[0:06] no specific starter kit in Laravel. So I
[0:09] decided to give an overview in this
[0:11] video in roughly 14 minutes or so to
[0:14] help you get started with fundamentals
[0:16] of APIs. This will be a shortened
[0:19] version of the fundamentals of my new
[0:21] updated course on Laravel API from
[0:24] scratch. So I reshot the videos, the
[0:26] video version. So all the lessons are
[0:28] video plus text. So the whole course is
[0:31] 1 and a half hours plus some text
[0:33] lessons. But in this video I will try to
[0:35] summarize the main things that you need
[0:37] to know in 14 minutes. But if you want
[0:40] the full course the link will be in the
[0:41] description below. Let's dive into
[0:43] creating APIs. The first thing you need
[0:45] to know is when you install the Laravel
[0:47] project, there's no API by default. So
[0:50] if you run Laravel new, none of the
[0:52] starter kits are for API projects. So
[0:55] you choose none and then you install API
[0:58] separately. Enable that functionality
[1:00] because it's not enabled by default
[1:02] since Laravel 11. So after that
[1:05] installation, if we go to the source
[1:06] code, there's no routes API file.
[1:09] There's only routes web. So you need to
[1:11] enable the API. By default, Laravel
[1:14] assumes that you don't have API and you
[1:16] don't work with API. So you need to run
[1:18] PHP artisan install API which will do
[1:22] two things. install Laravel Sanctum
[1:24] which we will later use for
[1:25] authentication including the migration
[1:27] for the tokens but also what is more
[1:30] important I'm sure if you noticed on the
[1:32] left now we have routes API file and the
[1:35] final thing to do with that installation
[1:36] is add Laravel Sanctum has API tokens to
[1:39] user model again for later
[1:42] authentication but in the routes now we
[1:44] have routes API where exactly we will
[1:46] put our routes for this video but to
[1:49] finish the installation in the user
[1:51] model let's have has API tokens which is
[1:54] autocompleted by my cursor like this.
[1:57] Next I will show you how to get the data
[1:59] via API. So this is the database table
[2:01] of categories and we will create a route
[2:04] and a controller to get that with the
[2:06] API call. So we make the controller I
[2:08] specifically specify namespace from the
[2:10] very beginning and then in the routes
[2:12] API we do route get categories
[2:14] controller with index and controller is
[2:17] used on top but in fact it's not correct
[2:20] autocomplete. It's this. Now in that
[2:22] category controller in the index method
[2:25] all you can do is just return eloquent
[2:27] collection and then Laravel will take
[2:29] care of returning that as JSON. So in
[2:32] your API client like Postman for
[2:34] example, you can just launch the URL
[2:36] which is powered by my Laravel herd the
[2:38] API is the default prefix of all URLs in
[2:42] routes API file and you just launch get
[2:44] request and get the list of categories
[2:47] with all the columns as they are from
[2:49] the database. But in real projects you
[2:51] probably want to customize the columns
[2:53] that are returned. For example, return
[2:55] just ID and name and not the timestamps.
[2:58] For that usually in Laravel people use
[3:01] so-called eloquent API resources. So we
[3:04] run artisan command make resource with
[3:06] model name resource and then it
[3:08] generates the file category resource
[3:12] which should return the array by default
[3:14] parent to array but this is where we
[3:16] override the defaults and return what we
[3:18] want to return from that category model.
[3:21] So for example, we want to return this
[3:23] ID, then this name and timestamps. And
[3:27] in this case, we don't want to return
[3:29] the timestamps at all. So let's leave it
[3:31] like this. And then in the controller to
[3:33] enable that eloquent resource, we wrap
[3:36] our category all into collection, which
[3:40] should be also added in the use section
[3:42] on top like this. Now if we launch our
[3:45] postman, the same URL, I don't change
[3:47] anything. I just relaunch. We have this
[3:50] changed in fact two changes. First we
[3:52] return only what is specified in the API
[3:55] resource but also we have a new wrapper
[3:59] layer called data which is closer to
[4:02] general API standards on the market
[4:04] outside of Laravel because there may be
[4:07] additional stuff in addition to data
[4:09] like pagionation like other related
[4:12] resources and stuff like that. But if
[4:14] you want you may disable that in your
[4:17] app service provider of Laravel project
[4:18] in the boot method you may specify JSON
[4:21] resource without wrapping like this. And
[4:25] now if we relaunch the same request we
[4:28] don't have that data but personally I
[4:30] wouldn't advise that this is kind of a
[4:32] standard and it's generally good to use
[4:34] market standards for the future. And let
[4:37] me show you that pagionation in action
[4:38] that I mentioned. So all you need to do
[4:40] to use pagionation from eloquent is
[4:42] change all to for example pagionate by
[4:45] default pagionate by 15 but we have only
[4:47] three records in the database. So we'll
[4:48] do pagionation by two records and that's
[4:51] all we need to do again laravel will
[4:53] take care of providing the structure and
[4:55] the fields automatically and let's
[4:57] relaunch that and see what happens.
[5:00] First we have the same data but as you
[5:02] can see two records only and then this
[5:05] is the reason why the data separately is
[5:08] useful. On top of data in addition to
[5:10] data you have links to all the pages you
[5:13] have meta data how many pages are in
[5:16] total what are the links for pages the
[5:19] link for next page and other settings
[5:21] related to pagionation. Next, I will
[5:24] show you the full crud of API based on
[5:26] the categories. And I already prefilled
[5:28] the code to save you some time. So to
[5:30] show a specific category, you just
[5:32] return the resource of that category.
[5:34] And this is where category source is
[5:37] useful because it's reusable. So when
[5:39] you launch get with categories ID1, this
[5:42] returns ID and name only. And this is
[5:45] all powered by route resource or in fact
[5:48] separate. There's route API resource
[5:51] which covers five methods instead of
[5:54] typical seven because APIs don't need
[5:57] create form or edit form. So there's
[5:59] only five methods index, show, store,
[6:02] update, and destroy. So I showed you how
[6:04] show works for store method. It's a
[6:07] typical Laravel thing. So if you worked
[6:09] with web Laravel, it's nothing really
[6:11] different. The difference is what you
[6:13] return. So you create the category, you
[6:15] validate the category and then return
[6:17] what if you use the same again eloquent
[6:20] API resource with new model created or
[6:23] updated model then again the structure
[6:25] is similar. So if you do the post
[6:28] request to add new category, you send
[6:30] the body name as new category. For
[6:33] example, we send and we get the data
[6:36] again with ID and name using Eloquent
[6:38] API resource. And by default for this
[6:41] case for create Laravel returns 201 HTTP
[6:45] status code instead of just 200 which is
[6:48] in the same 200 success status codes.
[6:51] And this is probably the most important
[6:53] part of working with APIs in general
[6:55] using correct HTTP status codes or at
[6:58] least the first number of two which
[7:01] means successful. And we'll return to
[7:03] status codes in a minute. For now I want
[7:05] to show the full CRUD. So this is what
[7:07] happens when you create a new category.
[7:10] Then for patch request or put it's
[7:12] almost the same put or patch. Then you
[7:14] do ID here and then you pass the name of
[7:18] updated category for example. Then you
[7:21] send and then it returns the updated
[7:23] category but this time with 200. Okay.
[7:26] And then finally destroy method. This is
[7:28] kind of interesting. So what do you
[7:30] return after there is no record in the
[7:32] database. It's deleted. Typical thing
[7:35] how developers return data here is
[7:37] response no content which would return
[7:40] status code 204. still two as the first
[7:43] number which means success but no
[7:45] content will be returned which is
[7:47] probably a good indicator for the front-
[7:50] end client that well there's nothing to
[7:52] show. So if we delete the category
[7:54] number three for example, we don't need
[7:56] any body in this case. But if we even
[7:59] pass that, it wouldn't be counted. We
[8:01] send and as you can see no content here.
[8:04] 204 status code here. And if we try to
[8:08] get that category by ID, we would get
[8:11] 404 not found. Which leads me to another
[8:14] tip. If you get HTML as a result, it
[8:17] means that you didn't pass important
[8:19] header. So in the headers of your API
[8:22] client whichever you use you do need to
[8:24] pass accept application JSON then if you
[8:27] get any error you get that error in JSON
[8:30] which is friendly for API client in
[8:33] JavaScript or whichever front end you
[8:36] have. Next let's talk about validation
[8:38] in Laravel and this is where we will get
[8:40] back to HTTP status codes. So what
[8:42] happens if we don't pass the name which
[8:44] is required. So in the controller we
[8:47] have request form request which has that
[8:49] rule of validation. By default Laravel
[8:52] in case of validation error will return
[8:54] 422 status code and will provide the
[8:57] list of errors related to those fields
[9:01] automatically forming the error messages
[9:04] similarly how it would do on the web
[9:06] just in JSON structure for the API. And
[9:08] this is okay this is how it's supposed
[9:10] to work. So your API client would see
[9:12] 422 status code and the first digit four
[9:15] means that the error is on the client
[9:17] side. So some data or some request
[9:20] didn't go well. So they need to fix the
[9:22] error on the front side like pass
[9:24] different data or pass different
[9:26] endpoint or something like that. But if
[9:28] you don't do the validation on the
[9:29] Laravel layer for example, let's remove
[9:32] that validation rule which would lead to
[9:35] SQL query being executed which will fail
[9:38] because on the database level that
[9:40] category name is required which then
[9:43] will lead to if we send 500 internal
[9:46] server error. And of course for
[9:48] production APIs you would have appV
[9:50] production so they will not see the SQL
[9:53] error because otherwise it would be a
[9:54] security issue. But generally when the
[9:57] API client sees 500 error or five
[10:01] whatever then means the error is on the
[10:04] server side. So the front end would need
[10:06] to report to you and you need to fix the
[10:09] error. So it's your job as a backender
[10:11] to do something like this. What I'm
[10:13] saying here is that 400 and 500 status
[10:16] codes are all errors but different in
[10:20] what should happen after that error. And
[10:22] the list of available HTTP status codes
[10:24] is pretty huge. You can find them on
[10:26] Wikipedia. So there's 200. Okay, we saw
[10:29] that 200 created and others, but
[10:32] probably you will use in your Laravel
[10:34] projects only a few of them. So I found
[10:37] this shorter list in Laravel docs for
[10:39] HTTP client which works with external
[10:42] API and these are the codes generally
[10:45] accepted which have specific methods
[10:48] which means that those are probably kind
[10:50] of the most probable HTTP status codes
[10:52] to happen. So you need to learn at least
[10:55] those. What do they mean and in what
[10:57] cases do they return these codes? But
[11:00] the basics of HTTP status code is this.
[11:03] I wrote an article on Laravel Daily.
[11:05] This is for premium members. But I will
[11:07] show you the point number one. The worst
[11:10] practice of API is returning 200 status
[11:13] code. If there is an error, you need to
[11:16] always rely either on Laravel automatic
[11:18] validation mechanism or specifically
[11:21] return 4 to2 or 500 whatever is the
[11:25] actual error. There's a classical meme
[11:27] about it and I found the original on
[11:29] Reddit here. So this is kind of the API
[11:31] client happily receiving the message but
[11:34] then inside of that message it says
[11:36] error. Finally in this video I will talk
[11:38] about Laravel Sanctum which is in itself
[11:40] a huge topic. So I will just give an
[11:42] overview from the doc. So you would
[11:44] understand the concept because how you
[11:46] use sanctum depends on what front end do
[11:48] you use it from. And in the course I
[11:51] have a separate big section with
[11:53] potentially most popular front ends
[11:55] Vue.js next and mobile flutter react
[11:59] native with repositories how you would
[12:01] use Laravel Sanctum for those. But in
[12:03] this video as an overview so you would
[12:05] understand the concept. If you use
[12:07] Sanctum for API token authentication, it
[12:10] probably means that you have front end
[12:12] separate like JavaScript application
[12:14] like Vue.js or any JavaScript which
[12:17] calls Sanctum to get the API token. This
[12:20] is where use has API tokens from user
[12:22] model is useful and you have a specific
[12:26] route to generate the token and return
[12:28] it to the front end and then all the
[12:30] requests from there from the front end
[12:33] should contain that token for
[12:34] authentication. And then in your routes
[12:36] you use middleware o sanctum which would
[12:39] check that token. Then the second way
[12:41] how you would use Laravel Sanctum is for
[12:43] so-called SPA single page applications
[12:46] which don't use any token and instead
[12:48] uses Laravel builtin cookie. So that is
[12:51] a separate topic. You need to configure
[12:54] domains. You need to configure
[12:56] middlewares and then for authentication
[12:58] you need to get so-called CSRF cookie
[13:00] and then configure some more stuff. But
[13:02] at the end in the routes, it's still
[13:04] middleware of sanctum. Similarly how you
[13:07] would use it in the first way. And then
[13:09] the final way is for mobile application
[13:11] authentication. It's almost the same as
[13:14] the first way. You issue tokens, but in
[13:17] this case you also have the request
[13:19] device name for example to assign the
[13:22] token to specific mobile device of the
[13:25] client. And then that mobile device
[13:27] should pass the token as bearer token
[13:30] and authorization header. And on the
[13:32] back end, same thing for protecting
[13:34] routes. In all those cases, it's
[13:35] middleware of sanctum to the route or to
[13:38] the route group. So yeah, this is the
[13:40] basic concept of how you use sanctum and
[13:42] the basic concept of how you use API in
[13:44] general. And this is where I will end
[13:46] this video. So the goal of this video
[13:48] was to get you started with the
[13:50] fundamentals of API. So you can go and
[13:51] create your APIs. You have enough
[13:53] knowledge. But if you want to get deeper
[13:55] and more practical again with Sanctum,
[13:58] separate examples also talking about
[14:00] uploading files and other features like
[14:03] documentation, versioning, rate limits
[14:06] and unit testing. I invite you to get
[14:08] the full course available for Laravel
[14:10] Daily Premium members as well as 80
[14:13] other courses at the moment. The link to
[14:15] that course will be in the description
[14:17] below. But if you have any more
[14:18] questions about APIs which I should
[14:20] touch in separate videos here for free
[14:22] on YouTube, let me know in the comments
[14:24] and let's discuss. That's it for this
[14:26] time and see you guys in other