Understanding HTTP Request Headers, Request Body, and Response Status Codes for API Testing

In API automation testing, HTTP request headers, request bodies, and response status codes are core components; understanding their purpose, format, and parsing methods is essential for effective testing.

1. HTTP Request Header

1.1 Purpose

Request headers are additional information sent by the client to the server to describe the nature, source, and data format of the request, helping the server understand the client’s needs.

1.2 Common Request Headers

Accept: specifies the content types the client can handle (e.g., application/json, text/html).

Content-Type: indicates the media type of the request body (e.g., application/json, application/x-www-form-urlencoded).

User-Agent: identifies the client type and version (browser, OS, etc.).

Authorization: used for authentication, usually containing a token or credentials.

Cookie: stores user session information.

Host: specifies the hostname and port of the request.

Referer: indicates the page that linked to the resource.

Content-Length: the length of the request body in bytes.

1.3 Example

GET /api/v1/users HTTP/1.1
Host: example.com
Accept: application/json
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Authorization: Bearer YOUR_ACCESS_TOKEN

2. HTTP Request Body

2.1 Purpose

The request body carries the actual data sent from the client to the server, typically used with POST, PUT, and similar methods, containing form data, JSON objects, etc.

2.2 Data Formats

application/json: JSON‑formatted data for structured information.

application/x-www-form-urlencoded: form data in key=value&key2=value2 format.

multipart/form-data: used for file uploads, supporting multiple data types.

2.3 Examples

JSON request body:

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

{
  "username": "testuser",
  "password": "testpass"
}

Form‑encoded request body:

POST /api/v1/login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 32

username=testuser&password=testpass

3. HTTP Response Status Code

3.1 Purpose

The status code is the server’s feedback on the result of the client’s request, a three‑digit number indicating success, failure, or other conditions.

3.2 Classification

1xx (Informational): request received and processing continues.
100 Continue, 101 Switching Protocols.

2xx (Success): request processed successfully.
200 OK, 201 Created, 204 No Content.

3xx (Redirection): further action needed by the client.
301 Moved Permanently, 302 Found, 304 Not Modified.

4xx (Client Error): request contains bad syntax or cannot be fulfilled.
400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found.

5xx (Server Error): server failed to fulfill a valid request.
500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable.

3.3 Example

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

{
  "status": "success",
  "data": {
    "id": 123,
    "username": "testuser"
  }
}

4. Parsing Response Codes

In automated testing, verify successful responses by checking for 200 OK or 201 Created and confirming the response body contains expected data. Verify error responses by checking for 4xx or 5xx codes and ensuring error details are present. Handle redirects by following the Location header when a 3xx code is returned.

5. Summary

Request headers describe additional request information, helping the server understand client requirements. Request bodies carry the data to be processed, commonly used with POST and PUT. Response status codes indicate the outcome of the request and are key to validating API behavior. Mastering these concepts enables more reliable and stable API automation testing.