Setting Up Our REST Client

In This Lesson

We'll take some time to get set up and get comfortable with a REST Client application. This will allow us to store our API endpoints within collections to simplify testing them as we build them out. In this series, I'll be using Hoppscotch

Created by: @tomgobich
Published: 1 year ago

Join the Discussion 0 comments

Be the first to comment!

Transcript

Now, when it comes to interfacing with our API so that we can test to make sure everything is working properly, we don't want to have to build out a completely separate application just to do that. Instead, that's where REST clients come into play.
Things like Hopscotch, Postman, or Insomnia. There's plenty of others. It's a very populated market. Allow us to target requests, set a HTTP endpoint,
specify request parameters, body header information, and save these to collections so that we can easily use and reference prior tests.
I'm going to be using one called Hopscotch here. Again, Postman or Insomnia are two very popular others. I already have this downloaded on my machine, but if you would like to use Hopscotch as well,
you can go to hopscotch.com, visit the download page, and they have a Mac, Windows, Linux, web app, and CLI version. So just download that to your machine or use the web version,
and it will look a little something like this whenever you open it up. Regardless of whether you're using Insomnia, Postman, or Hopscotch here, they're all going to relatively look similar. You're going to have tabs,
which are the current requests that you're working on. You can have multiple requests as well with an endpoint target within here. So you have the HTTP method that you can point to,
then the URL that you want to point to. You can send the request. Most of these allow you to save these and group them by collections as well.
Then you have parameter information for query parameters, body for body information, and header for header information.
Those are the only three of these that we're going to need to use for our API endpoint, but you also have authorization, pre-request scripts, and tests here as well.
So really quick, let's get our environment set up if you're using Hopscotch. So it's going to dump you into a personal workspace. Let's create one specific to our application instead.
So let's do plot my course and create a workspace just for our application here. This is going to allow us to have collections of
requests specific to just our plot my course application. In addition to that, it's also going to allow us to define environment variables for us to use throughout all of these requests as well.
Before we get into any of that though, let's first test our organization endpoint. So we want to send a get request, so that's a okay there,
to our HTTP;//localhost. The port that we're using is 3333, which is the default port for an AdonisJS server,
and then we've defined our route at /api/organization. Now, if we send it just like this,
we're going to end up getting back a 401 unauthorized response status with
the JSON body of an error specifying that we are not authorized to access this endpoint.
With Hopscotch here, you have a JSON pretty view as well as a raw view. Then you can view the headers, and then I don't believe test result is applicable to our use case here,
so that's going to be empty. So far, that's working as expected because we haven't specified an access token to use for this request.
This is an auth protected endpoint after all. So what we need to do is jump back into our application. So let's dig into our browser here.
I'm going to go ahead and close that tab out to get back into our application. I don't think I saved either of these two tokens. So let's go ahead and create a brand new one. I'm just going to have this match,
and I'm just going to call this development and give it all of the permissions here. So read, create, update, and delete. Let's create that token away,
give it a save, got my token, so we can close that dialogue, and let's jump back in the hopscotch. The way that we provide this access token to this request is via an authorization header.
So within our headers list here, we're going to want to specify an authorization as the key, and then for the value, we need to specify the type of token it is that we're working with,
followed by the token value itself. Now, the OAT tokens that we're working with here are considered bearer tokens because they grant authorization to a resource.
In our case, that's our organization and all of its information. So for the type of our authorization token, that's going to be bearer. Then we want to do a space,
followed by the token value itself, which we've copied from our application and will look just like so. So if we jump back up to the beginning of this string, we have bearer, space,
and then the token itself passed into our authorization header. AdonisJS will then read this to authorize our request and
authenticate our organization user for the endpoint on our request. So let's try sending this one more time, and look at that. We get back a 200 okay response now,
and then inside of our response body, we have our organization's information, its difficulties. If we scroll down further, we should have its statuses,
and further yet, its access levels. So awesome, that's looking a-okay, and our endpoint is working perfectly fine. Now, for each of these endpoints,
because we're going to have a list of them grow as we work on our API here, it would be great to not specify this localhost 3333 for all of them,
in the event that our port should ever need to change with maybe working on multiple applications at one point in time. So if we highlight this,
we can set this as a variable directly via our selection, but also we can jump over into the environments section, and right now we're working with
global environment variables within our plot my course application. But say for instance, maybe we wanted to test in other environments as well, like staging and production,
we could have those environment variables separated via an environment group. So if we add a new environment group here, we can call this development,
and we could specify our environment variables directly there, but let's save just this environment first, and now you can see that we have our development here. If we give that a click, it's going to open that panel back up.
Let's now add an environment variable, and I'm going to call this just API, as it's nice, short, and descriptive for what it's for.
We have a 0.2 HTTP; localhost 3333, and if you want to, you can even tack on slash API to that as well.
So let's give that a save, and now in order to use that within our endpoint we can get rid of our HTTP localhost 3333 API,
and instead do angled bracket, angled bracket API, and this is how you use variables within Hopscotch here,
and then end that with two more brackets. You'll see that right now this is red, meaning that it cannot be found, and that's because right now we're not working within an environment.
So let's switch this over to our development environment, and cool. Now it's green, meaning that it has been found. We can verify that by sending a request once more, and it works a-okay.
Should we ever need to alter that environment variable, we just come over to our environment section, click our environment there as development, and then we can alter it right there.
Lastly, let's go ahead and save each of these requests as we work on them, so that we don't have to rebuild them out and specify the authorization token that we want to use as we work on them.
So within our collections panel here, let's add a new collection, and we'll name these based off of the resources that our APIs are for. So we're going to have our organization here for our organization endpoint,
so we'll save that as a collection, and then within there, we can either add a request, or we can use the "Save" button here to save this already pre-built request to that collection.
So let's hit "Save" there. We can name this request, "GetOrganization", or whatever you like there, target it to our organization collection, and hit "Save".
That has now saved that within the organization collection panel, meaning that if we were to ever move onward from this, build out future requests, and that one gets closed away,
we can easily get back to it just by clicking on it within our collections panel. Now, we'll open it up, including the URL that we're after with
this environment variable and our authorization header that was last used and saved to that request. So that's the flow that we're going to be using here to make sure that all of
our API endpoints work as expected, and so that we can actually see the results as we build them.

Adding an API to an AdonisJS Web App

43 Lessons

5h 31m

Introduction

API Authentication

Getting Started with APIs

Organization Resources

Courses

Searching

Rate Limiting

Rate Limiting an Organization's HTTP Requests

13m 59s

Stop losing your best ideas!

Use our integrated note feature to capture and organize your key insights. Take a note at any timestamp and jump instantly back to that moment in the video with a single click.