Hi and welcome to the next section in
this course. In this section we're going
to continue to dig into hands-on API
testing. But up until now we've been
looking at static data, so we've been
looking at GET calls, calls that read
data that's there but don't change
anything. In this section we're gonna
look at changing data, so we're gonna
look at POST, PUT, and DELETE calls, and
see what happens when we change the data
on our service. So as you can imagine,
this gives us a whole new set of testing
challenges. Now we give API users the
ability to modify something on our
service, and so we want to make sure that
they can't do so in a harmful way. But of
course two main ways that people can
harm our app through bad POST calls.
First way is malicious users. We'll talk
a little bit about security testing in
your API later in this course, but that's
probably a full course in itself. The
second way though is through users
accidentally doing the wrong thing. For
example what happens if a user sends
their data in the wrong format, or if
they try to overwrite data that's
already in the system. There are many
things that could go wrong with POST
calls, and so in this video we're going
to look at how we can test POST calls.
Let's take a look at a real example of
this. So I have a local application here
that we'll use for demonstration
purposes. And for this application we can
pretend that it's kind of managing some
blog posts. So let's start with just a
GET call to the blog post URL, we'll send
that, and we can see we get back a couple
of sample blog posts here. So now let's
copy this, because we're going to need
when we do a POST we need parameters, we
need a body parameter. So change this to
POST, and now we have the body tab
available here. So let's go to that, and
let's actually put in raw data and then
we'll call it JSON. So the data that we
have here in our API is JSON formatted,
so we'll use that JSON option in Postman
to specify it. And we can see here this
is the inputs based on the GET call that
the POST call takes, or at least that
this blog posts URL produces. So we have
ID, we have a title, a body, and then a
profile ID that links it to which
profile created this. So for the first
thing here let's just try a few things,
let's get rid of the title here and see
what happens. So we'll get rid of that,
and we'll send this POST request and
we'll see what happens. So we send that
request, insert failed duplicate ID. Now
that's because we're sending the ID here.
So we're sending an ID of 1, but that ID
already exists in the system. And a POST
call is for creating new requests, so we
can't use an existing ID in the system.
So let's just try removing this, let's
see what happens if we don't have an ID
in here, let's send this call again, we
scroll down and we succeeded. Now we
probably should have changed the body on
this, since now we have two bodies that
are the same, but we can see that it
succeeded, however there's no name field
here. So if having a name or a title for
our blog post was important for business
reasons, we would want to check that in
the API, and we would want the API to not
allow us to send a POST request with
insufficient information. So this is one
kind of test that we can do with POST
request, is make sure that it requires
the things that are required, and it
checks for the existence of existing IDs
that we can only create new things. All
right so now let's try it, and let's just
see if we can explicitly specify our ID.
So we'll put the ID back in, and we'll
give it an idea of five because the next
one would be four right, we had an ID of
three here so the next one will be four,
but we'll say no or skip four and we'll
do five. And let's just give it a name as
well so that we have a properly
formatted, so let's just say test. All
right and we'll put a comma and we'll
send this. So if we scroll down here we
can see that it created a blog post with
an ID of five as we specified, so it
didn't increment next one, it used the
one that we specified. So now let's try a
few
interesting values, and let's see if we
can kind of break something here. So in
programming there's an interesting value
called double max, and that's the biggest
number that can be stored in a double
variable type. So let's try that number
here, we'll say 1 e to the 308, and let's
send that request and see what happens.
Ok it looks like it created it fine. So
let's see what happens if we go bigger
than that, ok 1 e to the 309, let's send
that and see what happens. Now we can see
down here it created the post for us but
it set the ID to null. Now if we were
testing this application we'd really
want to dig in and start exploring some
issues that might come from having a
null ID in our database. And actually in
this application there would be a number
of issues. But I'm gonna leave the
example here for now. I think it
establishes the point that we want to
check for invalid inputs, or unlikely
inputs because someone malicious or
accidentally might put stuff like this
into an API. So we want to check and see
how our API handles these kinds of
things. And then of course when we're
testing an API we need to consider many
other things, security, or performance,
making sure that calculated values are
properly recalculated when something
changes, and so many other considerations.
But the point of what I'm doing here is
to give you a bit of a glimpse, to give
you a bit of a feeling of what all goes
into testing POST calls, so that's when
you're looking at it you can think
carefully about how your particular API
works, and what inputs you might want to
do. Sso as with all parts of testing, you
need to explore and investigate and
continue to learn. In the next video
we'll look at testing PUT calls, it's
similar to POST but's a little bit
different, so hope to see you there.