-
we're going to be focusing on building our API, and for it, we're going to follow REST principles. Now, REST stands for Representational State Transfer, and it is essentially a list of
-
rules that describe how we should structure our API, so that it's easy to follow, easy to understand, and predictable. Now, in terms of those rules, they can be hard debated,
-
so we're going to be taking a practical approach here for our API, not following it to the T, but rather using it as a practical guide for what the requirements are for our application.
-
For the most part, in terms of our web routes, we've been following a REST-based style approach. You have your HTTP methods, which are our get, post, put, patch,
-
and delete that describe the action that we're doing for that route. Get for getting one or more of a resource, post for creating a resource, put and patch for updating a resource,
-
and then delete for deleting. Then you have the resource name, generally in a plural form, so lessons rather than lesson.
-
Let's scroll up to our courses here as it follows it completely. If we do a get for slash courses, we're after a list of our courses, that may be a paginated list,
-
that may be all of the courses. If we do a get for slash courses slash ID, we're after an individual course with the ID specified.
-
If we do a post to slash courses, we are creating a course. If we do a put or a patch to slash courses, we are updating a course,
-
and then since we have an ID route parameter on it, we're updating that specific course ID with the data from the body of the put or patch.
-
The difference between a put and a patch is debated as well. Typically, I like to keep puts for bigger updates, something that's updating all of a course in this instance,
-
or the vast majority of a course, and then patch for smaller updates, things targeting maybe a specific field on the course. For example, if you're toggling a like on a post,
-
you might use a patch to toggle that like on or off, and then delete, you're deleting the specific ID past, same as get and put there. So you're doing a slash for the resources name,
-
but then you can dig in further as well as we are here with our modules by targeting a specific resource and then a sub resource via a relationship. So our courses have modules,
-
so we can reach for a specific courses modules by doing courses slash the specific course that we're after, and then the related resource of that entity.
-
That then from there follows the same principle that we just followed with our courses as a whole in terms of getting, putting, patching, and deleting. Then one thing that we're not doing with our web routes
-
that we will do with some of our API routes is enabling the ability to filter. That is done via query strings. So that's not gonna come through with our route definitions per se,
-
but it is something that we will handle inside of the controller, ingesting those query strings in a filterable format, validating them, making sure that they match a structure that we're after,
-
and then we can filter the results of our get requests down from there. So let's start putting this all together by creating our first API endpoint.
