API testing basics

Picture a restaurant. You sit at the table (you're the app the user sees) and you want food from the kitchen (the server, where the real work happens). You don't barge into the kitchen. You tell the waiter what you want; the waiter carries your order back, and returns with your dish. An API is that waiter. It's the agreed way one piece of software asks another for something and gets an answer, without either side needing to know how the other works inside.

Almost every app you use is quietly chatting through APIs: your weather app asks a weather API for today's forecast, your shopping app asks a payment API to charge your card. When testers talk about API testing, they mean checking these conversations directly: skipping the buttons and screens, and talking to the kitchen's waiter ourselves.

REST and the four everyday verbs

Most web APIs today follow a style called REST. You don't need its full theory; you need its everyday grammar. In REST, you act on resources (a user, an order, a photo) using a small set of HTTP methods, the verbs that say what you want to do:

A key safety idea: GET should never change anything. Reading the menu shouldn't place an order. If a GET request quietly creates or deletes data, that's a bug worth catching.

Status codes: the kitchen's reply in three digits

Every time you ask an API for something, it answers with a three-digit status code that summarises how it went. You'll see these constantly, and they cluster into families. Learn the families and you can read any code at a glance:

The anatomy of a request and response

A request has a few parts: the method (GET, POST…), the URL (which resource), headers (extra info, like who you are and what format you speak), and sometimes a body (the data you're sending, usually as JSON). The response comes back with a status code, its own headers, and a body (the data you asked for). Here's a small, real example, reading a user, then creating one:

# Read a user (GET)
curl https://api.example.com/users/42

# Create a user (POST): send JSON in the body, prove who you are with a token
curl -X POST https://api.example.com/users \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Ada", "email": "ada@example.com" }'

A typical successful response to that POST might look like this, now that the server has created the record and filled in an id:

{
  "id": 1024,
  "name": "Ada",
  "email": "ada@example.com",
  "createdAt": "2026-06-24T10:15:00Z"
}

What to actually check when testing an API

Pointing at an API and getting a response isn't testing. Testing is checking the right things. A solid API test covers:

• Status code: did you get the code you expected (200 for a read, 201 for a create, 404 for something missing)?
• Body content: is the data correct, complete, and the right values?
• Schema / shape: are the fields present and the right types (a number where a number belongs, not a string)?
• Authentication: does it correctly block you without a valid token and allow you with one?
• Edge cases: empty fields, missing fields, wrong types, huge inputs, and requests for things that don't exist.
• Graceful errors: bad input returns a clear 4xx with a helpful message, never a raw 5xx crash.

Notice the pattern from earlier lessons returning: you test the happy path (a valid request that should work) and the unhappy paths (missing token, malformed data, a record that isn't there). The unhappy paths are where the real bugs live.