Methods, Status Codes, and Headers

The method, status code, and headers are three of the most useful signals in HTTP requests and responses. QA can often understand much of a problem before reading the body simply by examining these three elements.

Beginners usually focus on the response data: whether JSON arrived and whether a field is present or missing. This matters, but first you need to understand something more fundamental: what the client intended to do, how the server interpreted it, and what technical context accompanied the request. The method, status code, and headers provide that information.

Learning to interpret them confidently makes defect investigation much faster.

Method

The HTTP method expresses the client's intention: what it was trying to do, rather than the outcome.

→GET — retrieve data.
→POST — create an entity or trigger an action.
→PUT — replace a resource completely.
→PATCH — update part of a resource.
→DELETE — delete a resource or mark it as inactive.

In practice, teams do not always use methods perfectly, and you should account for that. However, QA still needs to understand their meaning. If a client sends GET and data changes as a result, that deserves attention. Creating an entity through GET violates API conventions and expectations around caching, repeatability, and safety.

Another important concept is idempotency. Some methods can be repeated without changing the intended result; others cannot. This matters for retries, repeated clicks, unstable networks, and automated tests. Accidentally sending the same request twice may have different consequences for POST and PUT, which your checks need to account for.

Status code

A status code is a brief technical summary of how a request was processed. It does not explain everything, but immediately identifies the result's category.

→1xx — interim technical information.
→2xx — the request was processed successfully.
→3xx — a redirect or an additional step is required.
→4xx — a problem with the client's request, data, or access.
→5xx — a server-side error.

These categories are enough for QA to get an initial sense of the situation. A skilled tester goes further and understands the most common individual codes.

→200 OK — the request succeeded.
→201 Created — an entity was created.
→204 No Content — the operation succeeded, with no response body.
→301 / 302 / 307 / 308 — redirects.
→400 Bad Request — the server will not accept the request in its current form.
→401 Unauthorized — the client is not properly authenticated.
→403 Forbidden — the client is recognized but does not have access.
→404 Not Found — the resource was not found.
→409 Conflict — a state conflict.
→422 Unprocessable Content — the request structure is valid, but its business meaning or data fails validation.
→500 Internal Server Error — an internal server error.
→502, 503, 504 — service boundary, overload, or availability problems.

The goal is to understand how codes help isolate problems, rather than memorize the entire table.

For example, 401 and 403 mean different things. A 404 can mean either "this URL does not exist" or "this entity does not exist." A 200 does not guarantee correct business logic. A 500 does not identify the exact point of failure, but quickly shows that the problem is beyond the frontend form.

Why 200 OK guarantees little on its own

One of the most common traps is assuming that an API returning 200 means everything is fine.

→Return incorrect data.
→Return an empty list where an object was expected.
→Hide a business error in an error field.
→Perform an operation only partially.
→Return stale data from a cache.

QA therefore always interprets the status code alongside the response body and scenario context. Technical success does not necessarily mean the product behavior is correct.

Headers

Headers supply additional context for a request and response. They often seem secondary until you investigate real problems.

→Data type (Content-Type).
→Expected response format (Accept).
→Authorization (Authorization).
→Cookies.
→Language or locale.
→Caching (Cache-Control, ETag, If-None-Match).
→Correlation identifiers.
→CORS policies.
→Security policies.

Headers are especially important to QA because they often explain apparently "strange" bugs.

→The backend expects application/json, but the client sends a different Content-Type.
→A token exists but was sent in the wrong header.
→A cookie did not arrive or was not saved.
→The cache returned an old version of the data.
→The browser blocked a request because of CORS.
→A reverse proxy rewrote some headers.
→The request specifies one locale, but the response uses another.

Headers are a substantive part of the protocol: they carry essential context. Without it, a request can be technically valid but logically incorrect.

How this helps QA in practice

Consider a bug: a user cannot save their profile.

The UI alone shows a single error message. The HTTP signals may reveal very different situations:

→A PATCH request was sent, but the server returned 400 because a field was invalid.
→The request was sent as POST even though the backend expects PATCH.
→The server returned 403 because the role lacks the required permission.
→The client sent the wrong Content-Type.
→The operation succeeded, but the frontend cannot handle 204 No Content.
→The request succeeds, but the cache or a page reload displays old data.

All of these may appear to be one "profile does not save" bug. For the team, they are six different classes of problems. The method, status code, and headers help identify where to investigate.

What QA needs to check

→Which method was used.
→Which URL was called.
→Which key headers were sent.
→Which status code was returned.
→Which headers came back.
→Whether the body matches the scenario's meaning.

With a systematic approach, network logs stop looking like "noise" and start revealing a clear structure.

Key takeaways for QA

→The method expresses the client's intention.
→The status code reports the technical result of processing.
→Headers convey essential context for requests and responses.
→200 OK does not guarantee that a business scenario completed correctly.
→Many defects are easier to isolate when you interpret the method, status, and headers together.