I have an API, that returns a 200 when I call it. Did it really work?
There are different ways we can test APIs, and checking the status code is just the beginning. In this series of posts, I’ll be taking up an API, and testing to see, if we can prove it actually works or not. I’ll be using Postman.

We talk about testing APIs, but what does it really mean? Status codes, are not enough. Relying on checking just them may be even dangerous. But we’ll leave that for later.

Testing Features, not APIs

Let’s start with changing the language. We can test APIs – see if they behave as we expect, and what happens when they don’t. Usually we do that against a spec or documentation. We can then say if the APIs work as expected.

However, most of the time, this is insufficient. Users don’t care about APIs – They care about whole features. And those usually combine multiple API calls. In addition, we need to test in the context of the actual, real calls that users are going to use.

So in terms of mindset, and actual testing, we need to think, not about a single API passing a test, but if a feature works.

Ok, once we got this out of the way, let’s start.

Behold! The JsonPlaceHolder API

We’re going to work with this site: it’s free, it exposes a model of a User->Blog posts->comments. And it’s simple enough for our purpose.

I warn you, this may get a bit confusing, because we’re going to use the word “POST” and in different meanings.

Let’s see how we can add a blog post to the database. We should do it, according to the specification, with an HTTP POST request like this:

Making a POST request for creating a blog post for userID using Postman for APIs Testing.

The POST request carries a JSON body. Let’s see what happens when we call the API:

Making a POST request for creating a blog post for userID using Postman for APIs Testing.

Ok, first of all, we got back a status code of 201. That’s HTTP code for Created. Yay! It works!
Are there other clues that this actually worked?

There are a couple. Let’s look at the response. First, we got an ID. That’s usually a good sign. It also mirrors what we sent in the body of the request. So the API works!

I’m still not convinced.

Let’s call the GET API. We’re looking to get the blog post we added, using the post ID we sent. Let’s see what happens:

Making a GET request for the blog post we created with the PostID using Postman for APIs Testing.

Hmm, weird. Not found.

Let’s try it another way. The following request should bring all the blog posts for this user:

Making a GET request for the blog post we created with the userID using Postman for APIs Testing.

Although I get a 200 code, nothing is returned. Still no sign of our record. Maybe there’s another way. Let’s get all of the blog posts, of all users:

Making a GET request for all blog posts with the userID using Postman for APIs Testing.

This time it’s a bit hard to find an answer. The JSON is big. But scrolling down, you can see there are only a 100 records. The ID it returned to me was 101.

What’s going on? And are there other ways to continue checking the feature? (spoiler, of course).

We’ll solve the mystery next time.

Categories: Uncategorized


Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *