VisaSpark
Sign in
beginner18 min

HTTP Fundamentals: Requests, Responses, and Status Codes

The shape of every HTTP request and response, and the status code ranges every API tester needs memorized cold.

What you'll learn

  • Describe the parts of an HTTP request and an HTTP response
  • Classify a status code by its hundreds-digit range and what that range means
  • Explain why a 200 status with an error message in the body is a testable defect

Explanation

Every API interaction is a request and a response, and both have the same basic shape: a method/status line, a set of headers, and an optional body. A request says: HTTP method (GET, POST, PUT, PATCH, DELETE), a path, headers (metadata like content type or an auth token), and sometimes a body (the data being sent, usually JSON). A response says: a status code, headers, and usually a body (the data being returned, or an error description).

Status codes are grouped into five ranges, and the hundreds digit tells you the category before you even read the specific number:

  • 2xx — Success. The request was received, understood, and accepted. 200 (OK) is the general case; 201 (Created) specifically means a new resource was created; 204 (No Content) means success with nothing to return.
  • 3xx — Redirection. The client needs to take additional action, usually following a new URL.
  • 4xx — Client error. Something about the request itself was wrong: 400 (Bad Request — malformed data), 401 (Unauthorized — no valid credentials), 403 (Forbidden — credentials valid but not allowed), 404 (Not Found).
  • 5xx — Server error. The request was fine; the server failed to handle it correctly. A 5xx is almost always a real bug worth reporting, not a data-entry mistake by the caller.

Here's the check that separates a careful API tester from a careless one: the status code and the body must agree. An API that returns status 200 (success) with a body containing { "error": "user not found" } is lying about what happened — a client checking only the status code would treat this as success and proceed with broken data. This mismatch is a real, common, and easy-to-miss defect: always verify the status code and the body tell the same story, not just one or the other.

Example

A simulated API response object and a check that catches the classic status/body mismatch bug. No real network request is made — this is fixture data.

// Simulated response — not a real network call.
const response = {
  status: 200,
  body: { error: "User not found" },
};

function isConsistent(res) {
  const bodyLooksLikeError = typeof res.body?.error === "string";
  const statusSaysSuccess = res.status >= 200 && res.status < 300;
  return !(bodyLooksLikeError && statusSaysSuccess);
}

console.log(isConsistent(response)); // false -- status says success, body says error

Try it yourself

Fix the response's status to 404 (matching the error in the body) and re-run.

Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.

Loading editor…

Guided exercise

Guided exercise

Write a function statusCategory(code) that returns 'success', 'client-error', or 'server-error' for codes in the 2xx, 4xx, and 5xx ranges respectively.

Checks: 200 is classified as success · 404 is classified as client-error · 500 is classified as server-error

Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.

Loading editor…

Stuck? Get a hint.

Independent exercise

Independent exercise

Write a function findStatusBodyMismatch(response) that returns true if the response is inconsistent: a status in the 2xx range but a body containing an 'error' string property (the bug pattern from this lesson), false otherwise.

Checks: detects a real mismatch · does not flag a normal success response · does not flag a correctly-matched error response

Code editor. Press Escape then Tab to leave the editor if keyboard focus becomes trapped. Press Control+Shift+M inside the editor to toggle Tab-key focus trapping.

Loading editor…

Stuck? Get a hint.

Common mistakes

  • Checking only the status code and assuming the body must be consistent with it — the two can and do disagree in real APIs.
  • Treating all 4xx codes as the same, when 400, 401, 403, and 404 mean meaningfully different things a tester should distinguish.
  • Assuming a 5xx response is the caller's fault — a server error means the request reached the server but the server failed to handle it correctly.

Knowledge check

Knowledge check

1. What does a status code in the 4xx range generally indicate?
2. An API returns status 200 with body `{ "error": "insufficient funds" }`. What should a careful tester conclude?
3. Which status range indicates the server received a valid request but failed to handle it correctly?

Takeaway

HTTP status codes group into meaningful ranges, and a careful API tester always verifies the status code and the response body tell the same story — not just one of them.

Summary

This lesson covered the shape of HTTP requests/responses, the meaning of the five status code ranges, and the classic status/body mismatch defect pattern.

References

Your notes

Notes save automatically.

Finished this lesson?

Mark it complete to track your progress and schedule a future review.

Next: REST Conventions and Resource Design →