-
Now, even though with our Git organization endpoint, we're already providing the organization's difficulty, statuses and access levels.
-
It's also a good idea to have separate endpoints to get each of those as well. And that's gonna go along with the resourceful pattern that we'll have for them too,
-
allowing us to also create, update and delete them directly via our API. So let's go ahead and jump into our terminal and do node ace make controller.
-
And we'll plop this inside of our API version one directory and call our controller difficulties. Lastly, so that AdonisJS stubs all of the needed methods
-
automatically for us, we can have it create an API controller by doing hyphen hyphen API, or just hyphen A for short. So we'll hit run on that, clear our terminal out,
-
and we can go ahead and hide our terminal away. Within our text editor, we now have inside of our API version one folder, a new difficulties controller,
-
and the hyphen A has stubbed us with an index store, show, update and destroy method. Inside of here, index is for getting a list of our resource.
-
In our case, that's gonna be our difficulties. Store is for creating, show is for getting a single resource, update is for updating our difficulties and destroy is for deleting them.
-
All right, let's hide that sidebar away to give us a little bit more working room. And first we want to just list out our difficulties for a get request to our difficulties controller.
-
Since we already have our organization within our HTTP context, we can reach directly for it and return our organization.related,
-
reach through to the difficulties relationship, query them. And then as we can note within the response body of our organization request,
-
these difficulties all have order fields. That's true for our statuses and access levels as well, noting what order they should be in.
-
And that's defined on a per organization basis. So we also want to order by that order field and we wanna do that in an ascending fashion
-
so we can go ahead and omit the direction as ascending is the default there. That should be all that we need to do there for our index method. So let's go and jump up
-
into our version one API route definitions and add a route definition for that. So we can do router.
-
And we could define this as get/difficulties and then rig this up to our controller that way. But since we're going to be implementing
-
all of the methods within our API resourceful controller, we could also define this as an API resource route definition which will define routes automatically
-
for each one of these methods in one go. Now, personally, I like to list out all of my routes without using the shorthand helper methods, but that's a personal preference
-
and listing all of the routes out is relatively straightforward. So let's go ahead and show how we can use the shorthand methods within this series. So rather than doing a straight get,
-
we'll do router.resource and we define the resource name as a string. So that's going to be our difficulties and then the controller that will handle the resource
-
which will be our difficulties controller. Now, again, just like our organization, we have two and we want to make sure that we reach for the one inside of our API directory. If you have multiple versions,
-
you want to make sure that you're grabbing the one applicable to the version to the route group you're defining the route for. So that's going to be our API version one difficulties controller. Since this is an API resource,
-
we also want to note it as such by doing API only. And that's just going to omit create and edit routes to show those create and edit forms
-
from a traditional web-based resource as API routes typically don't need those defined. Now I know in a previous lesson, I said that we weren't going to give these routes names.
-
I'm going to take that back and change my mind on it. Not because we need to reference these routes anywhere within our code, which would be the traditional purpose of naming these routes,
-
but because these router resources automatically come with a name. For example, if we were to try and send off our get organization request, which we verified works.
-
So if we send that off one more time, we're actually going to get a could not send request, essentially meaning that it could not reach our server. If we jump into our terminal,
-
head over to where I have the server running, we can see that we have a route with a duplicate name found because it already exists within our web route definitions. Now we could give a name,
-
API.difficulties to this resource by using the as method, but then we would have some of these routes with names and some without. We can fix this as a whole for our entire API group
-
for all resources that we ended up defining within here by giving the group as a whole a name. So if we call this API,
-
then all routes within it will be prefixed with API. So now our difficulty resource routes are API.difficulties.index,
-
taking care of that duplicate name. However, if we give this a save, that takes us to our next issue, and that's all routes inside of a group that has a name
-
must have a name as well, which our get right here for our organization does not. So let's go ahead and give that a name really quick, walking back on what I previously said,
-
and we'll just call that organization. Okay, we can give that a save, and now our server should be all back up and running. So we can jump back in the hopscotch, try sending that off one more time,
-
and cool, we get our response back at okay. Let's go ahead and create a brand new request and reach through to our version one environment variable
-
with an endpoint/difficulties. Leave the HTTP method as get, and if we send this off, we should reach the endpoint, but end up getting an unauthorized access error
-
because we have not yet specified our authorization header. So within our get organization, let's go ahead and jump back over into our headers, and let's go ahead and grab our bearer token
-
within our authorization header for this request, and let's set it as a variable. Within our scope, we'll select development, and for the variable name, we'll just call it our token.
-
Go ahead and give it a save, and that should simplify adding that token anywhere that we see fit. It should already be pre-selected because it was selected with our last request, but let's make sure that we have
-
our development environment selected there, and then we'll add in our authorization header,
-
reaching through to our token variable as its value. Okay, let's try sending that off one more time, and cool, there we go. We get back an array of objects
-
where each object is our difficulties. So we have easy, medium, hard, and expert there.
