REST API Testing with Postman: A Practical Exercise

By Andréia Ribeiro

Testing APIs is quite different from testing applications with a graphical interface, such as web, mobile, or desktop apps. Most modern web applications rely on RESTful APIs to communicate with backend services, making API testing a critical part of ensuring system reliability. In API testing, there is no visual interface. You don’t click buttons, fill out forms, or see messages directly. Instead, testing becomes more hands-on and structured: you prepare specific requests, work with JSON objects and their attributes, and include authentication tokens for each request.

In traditional UI testing, the focus is on the complete user experience. Testers follow workflows through forms, buttons, and interface elements, simulating how an end user interacts with the application from start to finish. The main goal is to ensure that all visible features work correctly and that the overall user experience is smooth.

In contrast, API testing focuses on individual components rather than the full interface. Testers interact directly with endpoints, send requests, check responses, and validate the data and behaviour behind the scenes. This approach requires a mindset shift: you need to understand how each layer of the application should be tested to ensure coverage, reliability, and overall quality.

During my mentorship with Júlio de Lima, I revisited API testing, this time approaching it with a tester’s mindset. Although I had used tools like Postman during my Higher Diploma in Science in Computing to test web apps I built, including Garage Booking App (Node.js, Express, MongoDB), this mentorship helped me deepen my understanding and apply more structured testing techniques.

I completed an exercise to deepen my understanding of how web applications interact with backend services, using tools like Postman and Swagger to validate endpoints. I tested a database API, applying my existing knowledge of Node.js and MySQL in a structured testing context.

The main steps I followed included setting up a local environment to run the API, understanding the database structure and its tables, testing REST endpoints, validating responses and authentication tokens, and documenting the testing process.

This combination of prior academic experience and structured testing practice strengthened my confidence in API testing and reinforced the importance of validating systems beyond the user interface.

Tools & Approach

Postman

Swagger (OpenAPI documentation)

VADER heuristic (focus on Errors)

Swagger documentation was used to understand endpoints, request structures, expected responses, and error codes. The Swagger file was imported into Postman to generate a test collection for login, transfers, and accounts, enabling structured testing. This approach allowed exploratory testing while validating:

APIs require technical interactions involving HTTP requests, JSON payloads, and authentication tokens. Data should be validated for type, format, size, and pagination. Understanding the API’s architecture and HTTP verbs (POST, GET, PUT, PATCH, DELETE) is essential. Each verb has a specific purpose, and testing them ensures consistency, reliability, and correctness, beyond the business rules.

VADER Heuristic

Heuristics guide testing by providing rules and guidelines. A well-known heuristic is VADER, created by Stuart Eschman in 2016. It provides a practical model for organising REST API tests and focuses on:

V – Supported HTTP verbs

A – Authorisation

A – Authentication

D – Data (types, formats, sizes)

E – Errors

R – Responsiveness

Following VADER ensures API testing is complete, structured, and reusable.

You can find more information about the VADER heuristic here

API Testing Exercise

This exercise tested the bank API created by Júlio de Lima, available on GitHub: banco-api. The repository contains prerequisites, business rules, and configuration details.

Objective: Validate the behaviour of key endpoints (authentication, transfers, accounts) using Postman and Swagger documentation.

Test Approach: Exploratory testing guided by Swagger documentation

Validation included:

Status codes

Response structure

Business logic

Error handling

Test Scenarios & Findings

🔹 Authentication – Negative Scenario

VADER focus:
✔ Authentication
✔ Errors

HTTP Request:
POST /login

Body:

{

"username": "invalid_user",

"password": "wrong_password"

}

Action: Attempt login with invalid credentials

Expected: Error response (401 Unauthorised)
Actual: Error returned as expected

✅ Endpoint handles invalid credentials correctly

Postman response showing correct handling of invalid login credentials:

🔹 Authentication – Access Forbidden Scenario

VADER focus:
✔ Authentication
✔ Authorisation
✔ Errors

HTTP Request:
GET /transfers

Authorisation: Bearer <token_user_without_permissions>

Action: Attempt to access the transfers endpoint with a user who does not have permission

Expected: Error response (403 Forbidden)
Actual: API returned 403 Forbidden

✅ Endpoint correctly restricts access for unauthorised users

Postman response showing access forbidden for unauthorised user::

🔹 HTTP Method Validation – Negative Scenario

VADER focus:
✔ Supported HTTP verbs
✔ Errors

HTTP Request:
GET /login

Body:

{

"username": "valid_user",

"password": "correct_password"

}

Action: Attempt to access the login endpoint using an unsupported HTTP method (GET instead of POST), even when providing valid credentials

Expected: Error response (405 Method Not Allowed)
Actual: API returned 405 Method Not Allowed

✅ Endpoint correctly restricts unsupported HTTP methods

Postman response showing method not allowed error:

🔹 Transfers – Positive Scenario

VADER focus:
✔ Supported HTTP verbs
✔ Authorisation

HTTP Request:
GET /transfers

Authorization: Bearer <valid_token>

Action: Retrieve transfers using a valid token

Expected: List of transfers returned

Actual: Response was successful. Status 200 (OK)

✅ Transfers successfully retrieved with valid authorisation

Postman response showing correct handling of transfer:

🔹 Transfer Update – Validation

VADER focus:
✔ Supported HTTP verbs
✔ Authorisation
✔ Data

HTTP Request:
PUT /transfers/{transferId}

Authorisation: Bearer <valid_token>

Content-Type: application/json

{
"contaOrigem": "6",
"contaDestino": "3",
"value": 150,

"token": "<valid_token>"
}

Action: Update transfer value (10 → 150)

Expected: Status 204 (No Content)
Actual: Behaviour matched documentation

✅ Transfer updated successfully with valid data

Postman response showing correct handling of updated value:

❗ Finding – Incorrect Error Handling

VADER focus:
✔ Data
✔ Errors

HTTP Request:
PUT /transfers/{transferId}

Authorisation: Bearer <valid_token>

Content-Type: application/json

{

"value": 150

}

Action: Send an invalid request body. I sent only the value, but contaOrigem, contaDestino, and token are also required.

Expected: 400 Bad Request
Actual: 404 Not Found

❌ API returns incorrect status code for invalid input

Impact: Returns an incorrect status code, potentially misleading consumers and complicating debugging. This issue should be reported to the team as a bug.

Swagger documentation for PUT transfer ID endpoint: