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, really HTTP requests. How you can see them in CUrl and in Postman, and why you should know about more than just one tool.

Last time we talked about what CUrl can do, and what happens when we make an HTTP request. We stopped at the request level, now let’s look at the response.

That’s a lot heftier than the request part. Let’s take a look.

The Mighty Response

The response has a mucho information. The first line contains the status (200). There’s a lot more that’s happening here (lots of header fields), but we’ll focus on a few important headers.

The first one is “Content-Type“, which tells the client the format of the response body. Remember, we asked for anything the server can send. But we need to be able to know how to read it, so we need to know the format (in our case JSON, or in HTTP-ese: application/json). It also contains the data encoding, utf-8, helping the caller to parse the response body correctly.

See the “Content-Length” field? It tells the client how big the response body is. Why? The client needs to allocate memory for that response. What if it is too big? The client can decide not to read it then. What if the response size is smaller than expected? The caller can do something about it, even before it started reading the response.

Another interesting header field is Server. I sent the request to JSONPlaceHolder.typicode.com, but in fact, the first server that it went through, was CloudFlare (which is a CDN, for our purposes, a Gateway). So we don’t know exactly where the answer came from, we only know the first server in line. We don’t know where the response, or the headers came from.

There are a lot more header fields sent back. All have some importance, and differnt clients can read them and do something with them. Finally, there’s the response body. The actual JSON response for my query.

That’s a lot of information going in there for a very simple request. That’s true for every request.

That Postman You Mentioned

Let’s see what happens in Postman for the same request. In the header section we’ll see this:

Let’s look at the header section. We see that “UserAgent” field, is pre-set as Postman and the version. Remember CUrl sent it’s own data?

Postman usually hides what we saw gets sent in CUrl. Can we see what we actually sent, and got back?
We can with the Postman console.

The Console logs the information for all the requests we send. We can see, it sends all the headers we’ve seen, which is bigger set than what we saw CUrl sends.

On the response side, we get the same list of headers we got at the CUrl request, because this server specifically, doesn’t care who’s calling, it returns the same fields.

All that’s hapenning under the hood of CUrl and Postman. As you can see, they are similar, but there are differences in what they expose.

But I’ve said that might be dangerous. Check out the next post for a certain mystery.

In the meantime, check out the my API testing workshops: