Demystifying HTTP

Beyond the Basics

Sep 25, 2025

When we test APIs, it is easy to focus only on the tools like Postman or automated scripts. But the real base of API testing is HTTP itself.
If you do not understand how HTTP works, your testing will stay shallow.

This guide explains the main ideas every Test Engineer should know and how to move from simple checks to real exploratory testing.

Quick pause: if you’re finding this interesting already, hit subscribe to LifeOfQA so you don’t miss future posts like this.

1. HTTP Methods:

GET – Retrieve data

Parameters go in the URL (query or path).
Should be safe, give the same result if run twice, and can be cached.

POST – Create new data

Data is sent in the request body (JSON or XML).
Not safe to repeat. Not cached.

PUT / PATCH – Update existing data

PUT replaces the whole resource.
PATCH updates only part of it.

DELETE – Remove data.

🔎 Tester’s View: These are common practices, not laws. Old systems or business needs may break these rules. Your job is to ask why.
If you see a GET call that deletes records, find out if it is on purpose or a risk.

Example: Request and Response

GET /users/123 HTTP/1.1
Host: api.example.com
Authorization: Bearer <token>

HTTP/1.1 200 OK
Content-Type: application/json

{
  “id”: 123,
  “name”: “Deepak”,
  “role”: “QA Engineer”
}

2. CRUD Mapping

CRUD actions map to HTTP like this:

🔎 Tester’s View: Organize your Postman collections or automation scripts around these CRUD actions. But do not assume the mapping is always correct. Sometimes “Update” is done with POST or “Delete” with GET. Use this table as a guide to explore, not a rule to enforce.

3. Status Codes: More Than Numbers

HTTP status codes show what happened:

1xx – Information
Rare in daily API testing.

2xx – Success

200 OK – Request worked.
201 Created – New resource created.
204 No Content – Success with no body.

3xx – Redirection

301 Moved Permanently
302 Found

4xx – Client Errors

400 Bad Request – Invalid syntax or data.
401 Unauthorized – Missing or bad credentials.
403 Forbidden – Auth present but access denied.
404 Not Found – Resource or endpoint does not exist.

5xx – Server Errors

500 Internal Server Error – Unhandled server bug.
502 Bad Gateway – Problem with upstream service.
503 Service Unavailable – Server is overloaded or down.

What a “Status Error” Means

4xx: The request is wrong. Maybe bad data, missing token, or a broken header.
5xx: The request is fine but the server failed. Maybe a database issue or code bug.

🔎 Tester’s View: Status codes are signals, not final proof. A 200 OK can still return a broken or empty payload. Always check the response body and headers, not just the code.

Example: A Failing POST

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  “name”: “”,
  “email”: “qa@example.com”
}

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  “error”: “Name cannot be empty”
}

This is a client-side error. Your bug report should show the exact request and full response, and explain that the name field is empty.

4. Reporting Bugs That Matter

When something fails, give developers enough to reproduce and fix it:

Include:

Endpoint and method (for example POST /users)
Full request payload (body, headers, query params)
Exact response (status code, headers if useful, and body)
Environment details (staging or production, build version)
Steps or preconditions (for example, “User must be logged in with role X”)

Example bug report:
POST /users gives 500 Internal Server Error when sending valid payload:
{”name”:”Deepak”,”email”:”qa@example.com”}
Expected: 201 Created.
Actual: 500 with message “Null reference in UserService”.
Reproducible on staging build v1.3.2.

Good bug notes save hours of back-and-forth.

5. Exploratory API Testing Tips

Go beyond scripted checks. Explore how the API behaves under stress or wrong use:

Try other methods: use PUT where only GET is documented.
Change payload size: send very large or empty bodies.
Break headers: remove Content-Type, send wrong values.
Play with auth: expired tokens, no tokens, wrong roles.
Test with many requests at the same time.
Simulate slow or broken networks.

These help you find hidden problems and weak spots.

6. Seeing Beyond Your Tool

Postman is useful, but you can learn more by watching real traffic:

Use a proxy such as Fiddler, Burp Suite, or mitmproxy to view live requests and responses.
Capture traffic from mobile apps or browsers to see what users really send.
Compare what the front end calls with what the API docs promise.

7. Security and Risk Checks

HTTP issues can lead to security holes:

Method misuse like GET deleting data can allow CSRF attacks.
Status code leaks can show internal details, for example stack traces in 500 errors.
Caching problems: cache poisoning or sharing private data.

🔎 Risk Thinking: When methods or status codes are used wrongly, ask:

Could this leak sensitive information?
Could someone use this unexpected behavior to attack the system?
What is the business impact if this reaches production?

8. Caching: The Bigger Picture

GET responses can be cached in many places: browser, CDN, or reverse proxy.
POST, PUT, DELETE should not be cached, but mistakes happen.
Distributed caches can return old data or be poisoned.

🔎 Tester’s View: Test with and without cache. Use headers like Cache-Control: no-cache to force a fresh response. Check what happens when the cache is not in sync with the database.

9. A Real Story: When HTTP Misled Me

I once tested an API that gave 200 OK even when a database write silently failed. Automation passed, but users later found missing data. The fix required adding proper 409 Conflict and 500 Internal Server Error codes.

Lesson: A green status code is not proof of success. Always check the meaning of the response.