Postman is great with visualizing API calls. But it’s not the only tool. Let’s see what happens under the hood of REST API calls, which are really HTTP requests. How you can see them in CUrl and in Postman, and why you should know about more than just one tool. Including a small mystery.

When we started we looked at CUrl, a command line tool for making API HTTP calls. Next, we looked at how to look at the request and response components in Potsman, and how they compare. We saw that we get the same response, although we saw what CUrl and Postman send, which are not the same headers. Which leads us to our cautionary tale – Don’t trust your tools. Too much.

Is the GitHub API broken?

Let’s get back to our command window. This time we’ll call Github. The call to should return a list of all the end-points, or APIs, GitHub exposes. Let’s see what happens.

Calling GITHUB API with CUrl and failing miserably.

Weird, we don’t see a response. Let’s see what happens under the hood.

Calling GITHUB API with CUrl and failing miserably, but with more details.

Ah, that’s better. So we get a 301 error code (Moved permanently) with same URL, but with HTTPS. Let’s do the same thing with Postman.

Calling GITHUB API with Postman and suceeding gloriously..

Hmm, we get a good response, the list of APIs, and a cool 200 status code. What happened?
Is Postman doing something different? Let’s look at the Postman console.

Calling GITHUB API with Postman and suceeding gloriously, but with the ugly details..

Oh. Look at that. Postman tried the original with HTTP, got the 301 code. The redirect Location field tells the caller where to go (same endpoint, but with HTTPS), So Postman made a second call, and succeeded, with the HTTPS version.

When we used CUrl, we only used HTTP and not HTTPs. And CUrl didn’t try the redirected version. The behavior in those two tools is different.

The Postman Sometimes Rings Twice

So what does that mean for us?

Every client does some magic work behind the scenes. Unless we understand how Postman (and CUrl) work, we might see things that we don’t understand. Or worse, think what we see is ok, but it actually hides something, like a bug.

In this case, if we only used Postman, and didn’t look at the console, we would think the HTTP version worked fine. Or, if we’re more optimistic, if we used just CUrl, we’d think that the HTTP version is “broken”. Regardless, there are two different results.

We used different tools to do the same thing, and the behavior was not completely identical. Postman is a good tool for visualizing requests, but we need to understand how it does its thing, and how to evaluate the result. Same with CUrl, and other tools.

Sometimes it helps to test with multiple clients. Remember, that the real user of the APIs will not be using Postman.

That’s it for this series. For more API testing deliciousness, check out the my API testing workshops:


Leave a Reply

Avatar placeholder

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