Testing APIs with Postman and curl

beginner
11 min

Testing APIs with Postman and curl

Before any frontend exists, you need a way to poke at an API: send requests, inspect responses, and reproduce bugs. The two industry-standard tools are curl, the command-line workhorse installed nearly everywhere, and Postman, a graphical client built for exploration and team collaboration. Fluency in both makes you dramatically faster at building and debugging APIs.

curl Essentials

curl sends an HTTP request and prints the response body. A plain GET is just:

bash
curl https://jsonplaceholder.typicode.com/posts/1

The flags you will use constantly:

  • -i include response headers in the output
  • -X set the method (POST, PUT, DELETE...)
  • -H add a request header (repeatable)
  • -d send a request body (implies POST unless -X overrides)
  • -s silent mode, hiding the progress bar for clean scripting
  • -o file write the body to a file

A realistic authenticated POST looks like this:

bash
curl -i -X POST https://api.example.com/api/v1/tasks -H "Content-Type: application/json" -H "Authorization: Bearer $TOKEN" -d '{"title": "Write curl lesson", "priority": 2}'

Two habits worth stealing: keep tokens in shell variables instead of pasting them into commands (they end up in shell history), and pipe JSON responses through jq for readable, filterable output, like curl -s .../tasks | jq '.data[].title'.

Postman Essentials

Postman wraps the same mechanics in a UI. You compose a request in the builder: choose the method, enter the URL, and fill tabs for query params, headers, and body (choose raw + JSON for API work). Hit Send and the response pane shows the status code, timing, size, headers, and pretty-printed body.

The features that make Postman more than a pretty curl:

  • Collections group related requests, such as every endpoint of your tasks API, and can be shared with your team or exported to version control.
  • Environments hold variables like {{baseUrl}} and {{token}}, so the same collection runs against localhost, staging, and production by switching a dropdown.
  • Tests are small JavaScript assertions that run after each response, letting a whole collection act as a smoke-test suite.
javascript
pm.test("status is 201", () => pm.response.to.have.status(201)); pm.test("returns an id", () => { const body = pm.response.json(); pm.expect(body.id).to.be.a("string"); pm.environment.set("taskId", body.id); // chain into the next request });

Saving the created ID into an environment variable, as above, lets the next request in the collection use {{taskId}} in its URL, so an entire CRUD lifecycle can run end to end with the Collection Runner.

A Practical Testing Workflow

For every endpoint you build, test four things in order: the happy path (does valid input return the right status and body shape), validation (does missing or malformed input return 400/422 with a useful message), authorization (do requests without a token get 401, and with the wrong user 403), and the edge cases from your spec (deleting twice returns 404, pagination past the last page returns an empty data array, not an error).

curl shines for quick one-offs, CI scripts, and sharing an exact reproduction of a bug in a ticket, because a curl command is copy-pasteable evidence. Postman shines for exploring an unfamiliar API and maintaining a living, runnable description of your own. Most developers keep both open.

Key Takeaways

  • curl with -X, -H, and -d can exercise any REST endpoint from any terminal.
  • Postman collections, environments, and tests turn manual poking into a repeatable suite.
  • Always test happy path, validation, auth, and edge cases for each endpoint.
  • Share bugs as curl commands; share API surfaces as Postman collections.

Next up: Building a REST API with Node.js and Express, where we implement a real server.

Testing APIs with Postman and curl - REST APIs | CodeYourCraft | CodeYourCraft