Hi and welcome. In this video we're gonna
talk about testing PUT calls. So testing
PUT calls are similar in a lot of ways
to testing a POST call, the difference is
that I PUT calls meant to edit an
existing object, rather than creating a
new one. For example things like what
kinds of data you might try to send, or
how you would authenticate the calls
might be the same between PUT and POST.
But there are a few things that we
should consider that are specific to
doing PUT calls. One of the most
important things is looking at which
fields we are allowed to change. Most
databases have an ID field, for example
that's used as a reference point for
building all queries, and so we often
don't want to be able to change that
once it's been created. Let's take a look
at our sample application and see if we
can understand what we're talking about
here. So we'll take a look again at blog
posts - one, let's send that so we can
get the data, we'll copy this, we'll
change our method here to PUT and we'll
go to the body, again we'll do raw JSON,
put this in here, and you can see we're
posting two blog posts slash one. But
let's try to change the ID, let's change
it to two and see what happens. So when
we post two blog post one is it going to
let us change the ID of that post to be
two? So let's send this and see what
happens. Now if we look down here it did
not modify the ID four, so it just
ignored that, which is good, we don't want
it to allow us to modify the ID. So
that's something we want to check with
POST calls or PUT calls, is to make sure
that when we put data it only lets us
modify the kind of data that we should
be allowed to modify. Another thing that
we might want to consider is how
associated data might change when we
modify an object. Again let's take a look
at an example to understand that. So
let's change this back to GET, and we'll
add a parameter here, so a question mark
underscore embed. And will embed comments
and send that request, and so we can see
that we've got our comments embedded
here in this. But this common
is associated with this blog post. So
what happens if we modify this comment?
So let's copy the body of this, let's
change the URL here to be comments / 1
because the comment ID here is 1, and
we'll put to that, so let's go here and
let's paste in the comment JSON that we
had, ok and then let's change something
here so we'll say changed, so we changed
the text of our comment, and let's go
ahead and send that. So we send that
request, you can see down here everything
went ok, it's changed. But now what
happens if we go back to that request we
had where we embedded the comments under
the blog posts. So we'll do a GET call
here, we'll send that, and we can see that
indeed the embedded comment has changed.
So that's good, that's what we wanted to
see, we wanted to see those changes to
the comment propagate into the blog post
and associated posts as well. And before
we leave this section I'm PUT testing,
let's take a look at just one more
example the kind of things you might
consider when doing this. Now this one's
sort of security related, and although
this course doesn't get into the details
of security testing on an API, there are
some basic things that we can think
about and and could check for. So in this
case what we want to check is what
happens when we try to PUT onto a blog
post that were not authenticated for, or
a comment that we're not entik ated for.
So in this example here I've got a
comment that the current user is not
allowed to see.
So we'll go change this to be comments /
-, and let's do a GET on there, and that
works okay. But now let's try to do a PUT
on it. So we'll change this to be a PUT,
let's take this and we'll put this here,
and let's
try changing this comment. So change it,
and now let's send this request. And if
we scroll down here we're unauthorized,
so we are not allowed to write to this
comment, maybe it was put there by
someone else and as this user we're not
allowed to write to it. Now this seems
good right, we got back a 401
unauthorized status, makes sense. But this
is actually a very minor security flaw,
by returning a 401 we've actually given
the user some information about the
system that they might not need to know.
So we've told them that this resource
exists. Now if you're a bad actor trying
to figure out some way to get into the
system that can be valuable information.
In this particular context is probably
not a big deal, but in some systems you
want to be careful that you're not
telling people that certain resources
exist by giving back this unauthorized.
Instead if someone is not allowed to
perform that action, it's usually better
to return a 404 or object doesn't exist
error. It's strictly speaking not the
right error, but from a security
perspective it makes more sense. And as
always there's a lot to learn and
explore in this area, but we'll wrap it
up here for now.
So feel free to keep exploring, trying
out new things, build out your own set of
testing ideas for PUT requests. In the
next video we'll dig into testing DELETE
calls, and we'll take a look at those,
hope to see you there.