← back to the section

When you click "Log in," the page doesn't decide on its own whether the password is correct — it sends a request to a server and gets a response back. This way of a program talking to a server is called an API. You can test not just buttons, but the exchange itself — directly, without any UI, with Postman: a request is assembled part by part, and a response is read as a status plus a body.

request response POST{{base_url}}/orders environment staging · base_urlhttps://staging.shop/api sent:https://staging.shop/api/orders headersContent-Type: application/jsonAuthorization: Bearer eyJhbGc body{ "customerId": 7,"items": [{"sku": "A-1"}] }Send 201 Created{ "id": 128,"status": "NEW","total": 1500 } expected 201 and an idactual matched expected removed 401{ "error":"unauthorized" }same request — 401a negative check a check = status and bodyagainst what you expect

A request is assembled part by part: the method and the address, where {{base_url}} is filled in from the environment, then the headers and the body. Send — and a response arrives: a status plus a body, and those are what you compare with what you expected. In the second half the token header is dropped from the very same request: the address and the body are unchanged, the answer is now 401 — that is a negative check, and for it such a result is the expected one.

What an API is in plain words

An API is the way one program talks to another. For a tester, the most common variety is the exchange over HTTP — the same protocol that websites use.

An analogy: an API is a waiter. You (the page) tell the waiter (the API) "bring me my list of orders," the waiter goes to the kitchen (the server) and comes back with the dish (data). How the kitchen works is not your concern: you place the order and check what was brought.

Why test an API separately from the UI:

  • Faster. Trying a dozen request variations directly is quicker than clicking through screens.
  • Deeper. The bug can be in the API while the UI hides it — or the other way round; a direct check tells you where it is broken.
  • Earlier. An API is often ready before the UI is — you can start before there are any buttons.

What a request is made of

A request has four parts:

  • Method — what we want to do. The main ones: GET (retrieve data — "show my orders"), POST (create — "create a new order"), PUT/PATCH (update), DELETE (delete).
  • URL (address) — where we're sending the request, for example example.com/api/orders.
  • Headers — metadata: data format, an authorization token (who we are).
  • Body — the data we're sending, typically for POST. Most often in JSON format — a simple text "key: value" form.

What a response is made of

Two things matter in a response:

  • Status code — a short summary. Worth remembering by group:
    • 2xx (200, 201) — success, everything is fine.
    • 4xx (400, 401, 403, 404) — an error on our side: bad request, not authorized, access denied, not found.
    • 5xx (500) — an error on the server. Almost always a bug.
  • Response body — the actual data (usually JSON): a list of orders, an error message, a created object.

Checking an API comes down to the same thing as everywhere else: compare the actual response — status and body — with the expected one. The status alone is not enough: 200 only says that the server answered. The comparison looks like this:

live example

// the status and the body of a response, copied from Postman
const status = 201;
const body = JSON.parse('{"id": 128, "status": "NEW", "total": 1500}');
console.log('status is 201:', status === 201);
console.log('order id arrived:', body.id !== undefined);
console.log('order is new:', body.status === 'NEW');
Run

Running examples is part of paid access. There the same code runs inside the article: editor, run and check next to the paragraph. Three free days →

In Postman itself the same lines live in the Tests tab: status and body come from pm.response, and the outcome shows up as a list of passed and failed checks.

First steps in Postman

Postman is an app, free in its basic form, where a request is built with the mouse: method, address, headers and a body when needed, then Send.

The address of a test environment is not typed into every request: it is stored in an environment variable and written as {{base_url}}/orders. Switch the environment — every request moves to another stand at once, instead of one by one.

A scenario to practise on:

  1. Pick GET, enter the address of an open training API (search for "public test API"), press Send — see status 200 and the data.
  2. Repeat with POST: send a body with new data — 201 and the created object in the response.
  3. Make a deliberately wrong request to a non-existent address — 404.

Three steps give you the "request → response → status" link. After that you check the same positive and negative scenarios: correct data, empty data, invalid data, no authorization. The request the page itself sends is visible in the Network tab — from there it is copied into Postman and the data changed by hand.

In short

  • An API is an exchange between programs over HTTP; it can be checked without a UI and earlier than the UI exists.
  • A request is a method, an address, headers and a body; a response is a status code and a body.
  • Checking an API is comparing the actual response with the expected one; the status alone is not enough, the body is checked too.
  • Code groups: 2xx — success, 4xx — an error in our request, 5xx — on the server, almost always a defect.
  • The address of a stand lives in an environment variable: {{base_url}}/orders — moving to another stand costs one switch.
  • Negative requests — without a token, with an empty body, with invalid data — find no less than the successful ones.