Software Testing API Testing
Behind every mobile app and website sits a hidden layer that moves data around. When a weather app shows today's forecast, it asks a server for data through an API. API testing checks that this hidden layer returns correct, fast, and safe responses without needing a screen.
What Is an API
API stands for Application Programming Interface. An API is a set of rules that lets one piece of software talk to another.
Restaurant Analogy
A diner sits at a table, a kitchen prepares food, and a waiter carries messages between them. The diner never enters the kitchen. The waiter takes the order, delivers it, and returns with the meal. The API plays the waiter.
CLIENT (App) --- request ---> API (Waiter) ---> SERVER (Kitchen)
<-- response --- <---
Why Test the API Directly
- API tests run early, before the screen exists.
- Tests execute quickly and fail with clear reasons.
- One API often serves web, mobile, and partner systems at once.
- Changes in the interface break fewer API tests than screen tests.
Anatomy of a Request
| Part | Meaning | Sample |
|---|---|---|
| Method | The action to perform | GET, POST, PUT, DELETE |
| URL | The address of the resource | /api/users/101 |
| Headers | Extra details such as format and access token | Content-Type: application/json |
| Body | Data sent with the request | {"name": "Asha"} |
Common HTTP Methods
- GET reads data.
- POST creates new data.
- PUT replaces existing data.
- PATCH changes part of the data.
- DELETE removes data.
Status Codes
| Code | Meaning |
|---|---|
| 200 | Success |
| 201 | Resource created |
| 400 | Bad request from the client |
| 401 | Not authenticated |
| 403 | Not allowed |
| 404 | Resource not found |
| 500 | Server error |
Example Test: Create a User
REQUEST
POST /api/users
Body: { "name": "Asha", "email": "asha@mail.com" }
EXPECTED RESPONSE
Status: 201
Body: { "id": 101, "name": "Asha", "email": "asha@mail.com" }
Checks to Perform
- Status code equals 201.
- Response body contains the new id.
- Returned name and email match the input.
- A follow-up GET request on /api/users/101 returns the same user.
- Response time stays under the agreed limit, such as 500 milliseconds.
Test Types for APIs
Functional Tests
Verify that each endpoint performs its job with valid input.
Negative Tests
Send wrong data, missing fields, and bad formats. The API should answer with a clear error and the right status code.
Security Tests
Confirm that endpoints demand a valid token and that users cannot read other users' data.
Performance Tests
Measure response time and stability under many simultaneous requests.
Contract Tests
Check that responses keep the agreed structure, so consumers do not break after updates.
Popular Tools
- Postman for manual and scripted requests
- REST Assured for Java-based automation
- Requests library with pytest for Python
- SoapUI for SOAP and REST services
Good Practices
- Keep each test independent and clean up created data.
- Store base URLs and tokens as variables, not inside test steps.
- Validate the response schema along with the values.
- Run API tests inside the build pipeline on every change.
API testing gives fast feedback on the core logic of a product. Teams that test this layer find defects long before users ever see a screen.
Reading a Failed Response
A failed API test tells a story through its status code and message. A 400 response with a clear message such as "email format invalid" shows that validation works. A 500 response signals a server defect, and the tester attaches the request, the response, and the time of the call to the bug report. Developers then find the matching entry in the server log within seconds.