Postman is great with visualizing API calls. But it’s not the only tool. I’ll show you what happens under the hood of REST API calls, how you can see them in CUrl and in Postman, and why you should know about more than just one tool. And if we look at other tools, we might learn something deeper about how HTTP requests are built, and how to test them.

CUrl is cool for looking under the hood of sending requests. Let’s take a look.

The Humble CUrl

CUrl is already on most computers as part of their OS installation. It’s a command-line tool to issue HTTP requests.
Let’s see how it looks. When you run “curl –help” to see the options, you can already identify options that are useful for calling APIs.

JSONPlaceHolder is a small server that you can use to play with HTTP requests. It features a simple model of users and their blog posts.

Let’s call a GET request:
curl http://jsonplaceholder.typicode.com/posts?id=10

As you can see, I didn’t write GET. That’s the default of CUrl. We can see the response we got, which is JSON. But not much else.

Let’s dig deeper. Using the “verbose” option, I can get more information of what’s happening below the radar.

Curl, but with details

Let’s do the same call as before, but with a -v (verbose):

curl http://jsonplaceholder.typicode.com/posts?id=10 -v

Ooh, that’s a lot more information. Let’s take a look.

That’s mostly the request part and the start of the response. The “prompt arrows” tell us if what we see is part of the request (pointing right) and the response (pointing left). The asterisks, is what happens before the request: Thr translation of the server from a name to an IP through a DNS.

We also see that I send a GET, with a relative URL to the HOST. That’s how requests URLS are broken down to bits. In fact, the HOST is a header field. And the protocol version “HTTP 1.1”. It tells the server how to interpret the request. All clients, including Postman (which we’ll get to soon) do that.

Some more request headers, please

Two things more to note on the request. The “User-Agent” header field tells the server who’s calling. It let’s the server know what to do with the request. For example, the server can decide not to answer browsers. Or not send images back to CUrl, which cannot see them (it’s just a text tool, after all). Also note, we’re sending the version of CUrl. That gives the server an option to reply differently to different versions. We’ll see what Postman sends later.

Also note, is the “Accept” header field. The “*/*” tells the server that it can send back any response format (CUrl is easy that way). We can also be more specific, like asking for JSON. Then the server can decide what to do about the request.

If we asked for XML, and it can’t provide it what then? We’ll discuss it later on. But for now, we’re ready to explore the response.

Next time, we’ll continue with the response in CUrl, and see what Postman does differently.

Check out the my API testing workshops: