API Testing Tools

Expected level: Working

API testing tools let you send a request by hand and examine the exact response, without writing a client application. The common choices are the browser developer tools, command-line clients such as curl, and graphical API clients.

Choosing a tool

  • The browser developer tools (Network tab) show what your web app actually sent and received. Many browsers can copy a request as a curl command.
  • curl is available on Linux and in current Windows versions (as curl.exe). It suits quick checks and scripts.
  • PowerShell Invoke-RestMethod sends a request and turns a JSON response into objects you can work with.
  • Graphical clients such as Postman, Insomnia or Bruno, or editor extensions with request files, suit saved collections, variables and sharing with a team.

Examples

# Bash: show response headers and body
curl -i https://api.example.com/items/1

# POST JSON with a token from the environment
curl -X POST https://api.example.com/items \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $API_TOKEN" \
  -d '{"name":"test"}'
# PowerShell
$body = @{ name = "test" } | ConvertTo-Json
Invoke-RestMethod -Method Post -Uri "https://api.example.com/items" `
  -Headers @{ Authorization = "Bearer $env:API_TOKEN" } `
  -ContentType "application/json" -Body $body

Useful curl options: -i shows response headers, -v shows the whole exchange, -L follows redirects, -s silences progress output and -H adds a header. In Windows PowerShell 5.1, plain curl is an alias for Invoke-WebRequest, so type curl.exe. Quoting JSON on the command line is error-prone, so put larger bodies in a file and use -d @body.json.

What to check in a response

  1. The status code (see HTTP Fundamentals).
  2. The headers, especially Content-Type and any rate-limit or caching headers.
  3. The body: is it valid JSON with the fields you expect?
  4. The timing: slow responses point to the server or the network.

Using the tools safely

  • Test against a development or test environment, and be careful with requests that change data.
  • Keep tokens in environment variables or the tool’s secret storage, never in shared collections or screenshots. See Secrets Management.
  • If a call works in the tool but not in your code, compare the two requests header by header.
  • Save the requests that matter as a collection or script. Teams often turn them into automated tests later.

Try it

Pick a public JSON API. Call it once with curl or Invoke-RestMethod, once with a graphical client, and look at the same request in the browser Network tab if it has a web front end. Then request a path that does not exist and compare the status code and body of the error.

Common mistakes

  • Typing plain curl in Windows PowerShell 5.1, where it is an alias for Invoke-WebRequest, instead of curl.exe.
  • Pasting a token into a shared collection or a screenshot.
  • Testing state-changing requests against a production system.
  • Hand-quoting large JSON bodies on the command line instead of using -d @body.json.

Check yourself

  • Which curl option shows the response headers, and which shows the whole exchange?
  • A call works in your tool but not in your code. What do you compare?
  • Where should an API token live when you use a testing tool?

Related topics

Terms

Further reading