Skip to main content

API Testing Tutorial Summary

By Updated

This page is a quick recap of the tutorial section. Use it to refresh the main API testing ideas, then follow the links back to the detailed pages when you need examples or more explanation.

Technology

  • Learn HTTP Standards
  • You can base your bugs on Standards
    • HTTP Message Syntax and Routing RFC 7230
  • Learn the common verbs: GET, POST, DELETE, PUT
  • Read the REST Dissertation

API testing starts with understanding the technology underneath the request.

HTTP gives us the basic request and response structure. REST gives us conventions for resources, verbs, and state. OpenAPI gives us a structured way to describe an API so tools and humans can understand it.

The core technical ideas to keep returning to are:

  • request line: verb, URL, HTTP version
  • request headers: metadata such as Accept, Content-Type, and Authorization
  • request body: JSON, XML, form data, or another payload format
  • response status code: what happened
  • response headers: metadata about the response
  • response body: the representation or error details returned by the server

When you know these basics, defects become easier to explain and you have an easy source of variation (all of this is a source of variation).

Never say "the API failed", you must be able to explain "the API returned 500 Internal Server Error when sent malformed JSON; I expected a client error such as 400 or 422."

Useful follow-on pages:

Testing

  • Add as much variation as you can
  • Use tooling to help you
  • Go beyond the outcome
  • Use headers
  • Read the Docs
  • Read the Swagger OpenAPI output
  • Combine everything you learned
  • Use a Client, send in requests as easily as possible
  • Use a Proxy, trust the proxy output rather than the tool output
  • Track your testing
  • Save HAR files to document your results

Testing an API means asking questions and collecting evidence.

Start with the documented behaviour, then vary one thing at a time:

  • the HTTP verb
  • the endpoint
  • path parameters
  • query parameters
  • headers
  • request body
  • content format
  • authentication state
  • data state

A useful test does not always need to be complicated. Sometimes a missing Content-Type header, an unsupported Accept header, or a request for a deleted item will reveal more about the API than another happy path request.

Good API testing also checks what happened after the response.

For example:

  • did POST actually create the item?
  • did PUT replace the expected resource?
  • did PATCH only change the intended field?
  • did DELETE remove the resource?
  • can another user now see data they should not see?

Use the response as evidence, but also check the system state when the operation is supposed to change data.

Useful follow-on page:

Tools - Clients

  • Different tools have different capabilities
  • Experiment with multiple tools
  • Postman: Collections for Data Creation, Console
  • Insomnia: Import, Timeline, Proxies
  • Import/Export between Tools

API clients help us create requests quickly and inspect responses without writing code.

They are useful for exploration, learning, debugging, setup data, and quick regression checks.

Different clients have different strengths. Some are better for collections. Some are easier to use with proxies. Some work well from local files. Some are better for scripting. Some are easier for beginners.

The site includes internal tool pages and reviews:

The best tool is the one that helps you vary requests, accurately see what was sent, accurately inspect what came back, and keep useful evidence.

The best tool probably doesn't exist, so combine tools (REST Client + a proxy) and learn the pros and cons of each tool so you have two or three tools that you switch between.

Tools - Proxies

  • Often used for Security Testing
  • Fuzzers create data
  • Automatically keep a record of your testing
  • View actual requests and responses
  • Replay requests

Proxies sit between the client and the server so that you can inspect the actual HTTP traffic.

API clients sometimes hide details, add headers, follow redirects, or transform requests before sending them. A proxy shows what really went over the wire.

Proxies are useful when you want to:

  • inspect raw requests and responses
  • compare tool output with actual HTTP traffic
  • replay a request
  • modify a request before it reaches the server
  • save evidence as a HAR file
  • investigate authentication, cookies, redirects, and headers
  • support security testing and fuzzing

Useful follow-on page:

Tools

Use more than one type of tool when learning.

  • A browser helps you see how web applications issue requests.
  • An API client helps you build requests deliberately.
  • A proxy helps you inspect the real traffic.
  • Automation code helps you repeat important assertions.

Each tool gives you a different view of the same system.

For practice, try sending the same request with:

  • a browser
  • cURL
  • a GUI API client
  • a proxy observing the request
  • an automated test

Then compare what each tool shows you. This is a good way to discover hidden headers, redirects, cookies, default content types, and other details that affect API behaviour.

Automating

  • HTTP libraries
  • REST libraries
  • Domain Abstractions
  • Reuse for performance testing

Automation helps when you have assertions worth repeating.

Start by learning the API interactively. Use a client and proxy to understand the request and response. Then automate the stable checks that provide ongoing value.

Automation can use low-level HTTP libraries or higher-level REST libraries.

Low-level HTTP libraries give you control. Higher-level REST libraries often make common tasks easier, such as serialising JSON, adding headers, and checking response bodies.

As an automation suite grows, domain abstractions become useful.

For example, instead of repeating raw POST /todos request construction in every test, you might create helper methods such as:

  • createTodo
  • getTodo
  • deleteTodo
  • createAuthenticatedUser

Keep the abstractions small enough that you can still see what HTTP behaviour is being tested.

Automation code can also support performance testing, setup data, cleanup, monitoring, and repeatable bug reproduction.

Testing Summarised

  • Requirements - domain, documentation, SDK
  • Standards - HTTP, REST, Auth
  • Security
  • Capacity
  • Interfacing Systems

A useful API testing model combines several sources of ideas.

Requirements tell us what the API should do for the product.

Standards tell us what HTTP and REST behaviour usually means.

Documentation tells us what this API claims to support.

Tools show us what is actually sent and returned.

Risk helps us decide where to spend more time.

When testing, keep asking:

  • what does the documentation say?
  • what does the standard suggest?
  • what does the system actually do?
  • what could harm a user, client, or downstream system?
  • what evidence do we have?

Summary

API testing is a combination of technical understanding, practical tooling, and risk-focused thinking.

Learn the HTTP and REST basics so you can read requests and responses. Use API clients and proxies so you can create, vary, inspect, and record traffic. Read the documentation and OpenAPI output, but compare it with the real behaviour of the system.

Then turn what you learn into lightweight notes, saved requests, proxy captures, and automated checks. The goal is not only to see that an API responds, but to understand whether it behaves correctly, consistently, and safely for the clients that depend on it.

 

Copyright Compendium Developments Ltd 2020 - 2026