In this video we're going to cover some more advanced postman features.
That's going to make it a bit easier to use this tool especially as the number of requests we're working
with continues to grow.
So we're going to take a quick break from writing code and Visual Studio code and we'll focus on improving
our postman workflow making it a bit easier to test out the requests that our API supports and to get
started.
When I want to talk about our postman environments and postman environment variables.
To illustrate how environments are going to play a role in postman let's start off with an example.
So right now all of our requests are being made to local host three thousand and that's good because
that's where our server is running.
Later on in the class though we're also going to deploy the task manager API to Heroku and in that case
we'll have a different U.R.L..
We're also going to want to test those production and points from postman and that would mean US manually
swapping out you are ELLs for a dozen or so different requests.
I would have to go into each and change that you are all back and forth as I wanted to change which
server I was making the request to with postman environments.
We can set up an environment with various variables.
These can be used to configure how postman runs.
And that's exactly what we're gonna do.
We're going to do it for you are elves and we're also going to do it for our authentication tokens.
Let's get things started with a very basic example though we're going to focus on that create user end
point we'll end up working down this list and they create user endpoint like all of them has the you
are L hardcoded we're gonna address that now up above and the top right hand side we can see this know
environment dropdown if I expand it we don't have any environments to pick from but we can go ahead
and create our very first one right here I'll go ahead and set up an environment by clicking that gear
icon which opens the manage environments panel.
Now once again we don't have any.
I can click Add to create the first one and right here we'll pick a name.
I'll go ahead and use Task Manager API followed by death.
So this will be the task manager API running in development mode.
So all of the environment variables will be for that where the U.R.L. would be local host three thousand
down below we can set up key value pairs for the various environment variables we want to create.
For example I could create one called U.R.L. and I could set the value equal to local host three thousand.
Let's take a quick moment to knock that out.
Now we have initial value which is what we set.
And then we have the current value.
So it could get changed later on although in the case of U.R.L. it'll never get changed.
So right here we can now click Add to create our brand new environment and we could always go ahead
and create another.
Let's take a quick moment to do that as well.
Right here I can call this one task manager API.
Then in parentheses abroad which is short for production.
Now I don't know what the production you are ELAs.
So I'll leave that blank for now though I will create the environment as a place holder down below I'll
click add.
And now we have two environments to pick from.
If I close the environments modal pop up I can go back to that no environment dropdown and I can see
my two options.
So I can click over to this one to start running requests on the dev server and I can click over to
this one to start running requests on the production server.
Now let's go ahead and actually figure out how to use that you are well variable we set up so I'm going
to switch back over to the dev environment and we're going to adjust the U.R.L. we have right here.
Oh we're gonna do is take local host three thousand and remove it.
We're still going to leave the forward slash users as that part the path will change for every request
right here to use and environment variables value.
We start by opening and closing two sets of curly braces.
Then we name the environment variable.
We're trying to use in this case it's you are El now with this in place when we make the request that
you are El value will be used and the dev environment has that defined.
If I actually hover over that little part I can see the value that's going to be used which is fantastic.
And if I go ahead and send this off it's actually going to work as expected I'll click save first then
send and what do I get down below it's actually able to communicate with the server correctly even though
that email is already take.
Now if we were to switch over to the production environment all our requests would fail because there's
no you are well defined and that's OK for now from here.
Let's go ahead and work down the list making sure we use the you are El environment variable.
So I have a log in.
I'll go ahead and update that and then I'll go ahead and save things.
Next up in the list we have create task.
I'll make sure to use the environment variable there and save it.
We have read profile after that we have a read user from there we have read tasks.
Next up we have read at task individual then we have the ability to update a user.
We're going to swap out the value there and just three more left update task and then we move on to
our delete end points.
I have delete user and I have delete task.
Now if you thought that was annoying you're right.
And that's the whole reason we're setting up these environment variables.
Yes we had to do it once but it's done.
And now when we want to swap out the U.R.L. in the future we'll never need to manually do that again.
We can change the environment variable a single time or switch between environments to have all of our
requests automatically update.
So that's the first thing I wanted to accomplish in this video.
The next one is a little more complex and also a little more useful.
And it has to do with how we're setting up authentication.
So over here read profile is currently the only request that actually has authentication set up and
to authenticate it's providing the token as part of a header.
Now we can continue to do that but there are better ways to get the job done.
If I fire this off yes it works.
But now if I wanted to add authentication to my other requests it would fail.
Let's go ahead and talk about how we can update multiple requests to all use the same authentication
scheme.
So right here we're going to grab that token value.
We're not going to grab the space or the bearer keyword.
We just want the JWT and we're gonna go ahead and delete this header completely.
Now this is going to cause the request to fail which is OK we're not authenticated and that's expected.
What we're going to do from here is head over to the authorization tab.
This provides us with a different way to set up authorization and it's only different in terms of the
user interface in the end of the day the exact same request is getting sent from postmen to the Express
server from this type dropdown.
We're going to switch it up to the following which is bearer token.
That's the strategy we're using where we provide the authentication token and then we can go ahead and
paste that right in here.
This is just a different way to get done exactly what we were getting done before I go ahead and save
that request.
I fire it off and now we're back to a working app.
Now this does indeed work.
But once again it's only working for this specific request.
So this is not the approach we're going to take.
What we're gonna do is switch the type back to the type we had before which is inherit off from parent.
This allows us to define our authentication scheme once and use it in every single request that has
this type under authorization.
And it's the default type which means all of them to actually get this done.
All we have to do is take our authentication token over to the following menu for the task collection
will click that drop down menu from here.
We're gonna go to edit and from edit we're going over to the authorization tab.
Now this is exactly what we just saw before.
But instead of setting up authorization for a single request we're setting it up for every single request
in this collection.
Right here we're going to switch from no.
Off to bearer token and we're going to provide that token value.
I'm going to update the collection.
And with that in place any request that has authorization set to inherit is going to be able to authenticate
without needing to do anything manually.
So right here I can send this off and what do I get.
I'm still authenticated even though it's not set up anywhere in the individual request.
I can see under header it's showing up a little bit but this is just showing up because it's giving
us a preview of that collection header we had set before.
So now that we have this in place all of our requests are going to be authenticated but we can still
customize things further.
We know that create user and log in user don't require authentication even though their authorization
value is inherit by default.
We can always switch that up to no.
Off to disable authentication for both of those.
I'll go ahead and disable it for create user and say that and I'll do the exact same thing for log in
updating authorization over to No.
OK now for all of the other requests as an example update user that's already the authorization value
so all of our requests are inheriting from the off parent.
So they're getting that token set correctly except for sign up and log in and that is exactly what we
want.
Now there's just one more thing we're going to do to take this to the next level.
And this is going to require us to set up a little bit of JavaScript code to perform some automation.
So what's the one manual part of this workflow.
The manual part is either creating a user and logging in then getting that off token going back over
to that menu to update the value and then being able to make their requests.
We can have all of that done automatically for us by writing just three or four lines of javascript
code.
Now all the code we're going to write is going to live in the following menu for both create user end
log in user it is the tests menu.
So we have pre request script where we can add some javascript code to run before the request is sent
off.
In this case before the log in at request is sent off.
We also have tests.
Now this runs after the response is received and in here we can write some javascript code to extract
that token property on the body and set an environment variable whose value is equal to that token.
From there we'll use the environment variable inside of the collection to get everything working as
expected.
So let's start by editing our collection.
Just one more time right here under authorization no longer are we actually going to list out a Jason
web token.
Instead we're going to reference an environment variable we'll call this off token.
Now it currently doesn't exist but we're about to write some code to set it so I will update the collection
and we're going to start in the tests tab for the log in user request right here the first thing we
want to do is make sure that the request succeeded.
We want to make sure we got a 200 status code we can use and if condition to check that right here if
and postman gives us access to an object P. M. We can use when we're writing our little pre request
script or test code in this case we can use something on p.m. to get the status code it is p.m. which
is short for a postman dot response dot code.
This is a number and we're going to check and see if it's two hundred if it is two hundred will run
the code that actually sets the environment variable now in this case PND contains another thing we
can use to set the environment variable that is M. dot environment p.m. dot environment contains a method
set and we can use this to set the value for an environment variable in our current environment.
So we have a key value pair where both are strings we have the environment variable name we're trying
to set.
We just call that auth token before and then we have the value we're trying to use now in this case
we know the value it lives on that response body so down below we have the response for one of our previous
requests here is the body and at the very bottom we have that token property this is the value that
we need to get but we need to get it from our test script.
So right here instead of passing in a string like we were doing previously we're gonna go ahead and
grab the code from somewhere else.
We're going to access something else on p. m. It is P. M. dot response dot Jason.
This is going to take the Jason response and convert it to an object and the object is the return value.
So on this object the only thing we need access to is token.
So dot token and there we go.
Now we have a script that's going to set the authentication token automatically.
Anytime we log in.
So if our token expires I can run log in a single time then I can go to any of the other requests to
run them and make sure things are working as expected.
Let's go ahead and test this out.
I'm going to move over to read profile and I'm going to run this request before I ever run log in when
I do I'm not authorized which is expected.
Now I run log in which should automatically set that token for me.
The log in request finished and I'll head back over to read profile.
This time it should work.
I'll fire it off for a second time and it does indeed work which is fantastic.
Now the last thing we're going to do is take our code in this test tab and we're going to bring it up
to create user right here we'll go over to the tests tab again I'll paste the exact same code in and
the only thing I'm going to do is change the status code we're looking for when we create a user we
get a two a one back when things work well so we can save that.
And now we're done.
So now we have a completely automated system.
Yes we have to log in once but everything else is handled behind the scenes for us no longer are we
gonna have to copy and paste values around or manually change you or else this is going to make it a
lot easier to continue to use postman especially as we set up authentication for the other end points
that our API supports.
Let's take a quick moment to head back over to that gear go back to the dev environment by clicking
on it.
And here we can see that you are well has the same value as before and off token has the current value
equal to this what we're seeing over here the J WTI there's no initial value because we never manually
typed anything in here and that's fine.
There is no default auth token we would want it should get set as the response from either signing up
or logging it.
So let's take a quick moment to recap because we covered quite a bit in this video we started by creating
postmen environments and environment is nothing more than a name for your environment and a key value
pair of values you can access when working in that environment.
So in this case under the dev environment and for the task manager API we have you are well.
And we have token if I go back to the menu and go over to prod we have nothing and that's OK we'll focus
on setting that up later.
Now once we have our environments in place we can switch between them.
The other menu up top and we can access those environment variables from anywhere such as that you are
L right here or such as the collections edit page where we set up authentication for every single request
in the collection except for signing up or logging in.
Now if you have any questions about what was covered here or you're not clear on why we're doing something
just crack open a new question in the Q and A otherwise I'll see you in the next lesson where we get
back to visual studio code and we continue to build out the API.
Let's go ahead and jump right in.