HTTP Requests and Responses: API Request Format, Headers, Body & Parameters

HTTP Requests and Responses

Every API test is a conversation: the client sends an HTTP request, the server sends back an HTTP response. Knowing exactly what's inside each — and what can go wrong in every part — is what turns "the API works" into a real test. This guide walks through both messages piece by piece, with examples in raw HTTP, curl, Postman and REST Assured.

A Complete Request and Response

POST /api/v1/users?notify=true HTTP/1.1          ← method, path, query, version
Host: api.example.com
Authorization: Bearer eyJhbGciOi...                ← headers
Content-Type: application/json
Accept: application/json

{ "name": "John", "email": "john@example.com" }   ← body

HTTP/1.1 201 Created                               ← status line
Content-Type: application/json                     ← headers
Location: /api/v1/users/101
X-Request-Id: 7f3c2a

{ "id": 101, "name": "John", "email": "john@example.com" }   ← body

Keep this picture in mind — every section below is one part of it.

Endpoints

An endpoint is the URL where a resource or operation lives: a base URL plus a path, such as https://api.example.com/api/v1/users. Combined with a method it defines an operation — GET /users/{id} reads one user, POST /users creates one.

RESTful endpoints use nouns (/users, /orders/55/items), not verbs (/getUsers) — the HTTP method already says what to do. Many APIs also put a version in the path (/v1/), which is worth testing when a new version ships.

The Request

1. Method

What to do: GET, POST, PUT, PATCH, DELETE. Details and examples: HTTP Methods & Status Codes.

2. URL — path and query parameters

Path parameters identify a resource: in /users/{id}, the request /users/123 means user 123. Query parameters modify the request: /users?status=active&page=2&limit=10 filters and pages the list.

Special characters must be URL-encoded: a search for john doe&co becomes ?q=john%20doe%26co. Tools such as Postman and REST Assured encode for you — hand-built URLs often don't.

3. Headers

Key–value metadata about the request:

Content-Type vs Accept: Content-Type describes what you send; Accept describes what you want to receive. A wrong Content-Type typically returns 415; an Accept the server can't satisfy returns 406. More on auth headers: API Authentication.

4. Body

The data sent with POST, PUT and PATCH (GET and DELETE usually have none). Common formats:

More on JSON and XML: JSON & XML in API Testing.

The Response

1. Status code

Three digits that say what happened: 2xx success, 3xx redirection, 4xx client error, 5xx server error. Full list: HTTP Status Codes Cheat Sheet.

2. Headers

3. Body

The returned data — usually JSON. Test the values, required fields, data types, arrays and nested objects, and validate the whole structure against a JSON schema. Error responses have bodies too: check they're structured and helpful, without stack traces or internal details. Related: Negative Testing & Error Handling in REST Assured.

The Same Request in Three Tools

curl

curl -X POST "https://api.example.com/api/v1/users?notify=true" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"John","email":"john@example.com"}'

Postman

Method POST, URL {{baseUrl}}/api/v1/users, the Params tab for notify=true, the Authorization tab for the bearer token, and Body → raw → JSON for the payload. Path parameters use :id in the URL (/users/:id) and appear in the Params tab. More: Postman Cheat Sheet.

REST Assured

given()
    .baseUri("https://api.example.com")
    .header("Authorization", "Bearer " + token)
    .contentType(ContentType.JSON)
    .accept(ContentType.JSON)
    .queryParam("notify", true)
    .body(Map.of("name", "John", "email", "john@example.com"))
.when()
    .post("/api/v1/users")
.then()
    .statusCode(201)
    .header("Location", containsString("/users/"))
    .body("id", notNullValue());

given().pathParam("id", 101)
.when().get("/api/v1/users/{id}")
.then().statusCode(200).body("name", equalTo("John"));

API Request Format: A Real Example

Here is a real request and response, captured with curl -v against a small test API. Lines starting with > are what the client sent; lines starting with < are what the server returned:

curl -v -X POST "http://localhost:8765/api/users?notify=true" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "Authorization: Bearer test-token-123" \
  -d '{"name":"Asha","email":"asha@example.com"}'

> POST /api/users?notify=true HTTP/1.1
> Host: localhost:8765
> User-Agent: curl/8.5.0
> Content-Type: application/json
> Accept: application/json
> Authorization: Bearer test-token-123
> Content-Length: 42
> 
< HTTP/1.1 201 Created
< Content-Type: application/json; charset=utf-8
< Location: /api/users/42
< Cache-Control: no-store
< Date: Sun, 04 Oct 2026 09:24:41 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< Transfer-Encoding: chunked
< 
{"id":42,"name":"Asha","email":"asha@example.com","createdAt":"2026-10-01T09:30:00Z"}

Every API request has the same format: a request line (method, path with query parameters, HTTP version), headers, an empty line, then an optional body. The response mirrors it: a status line (201 Created), headers, then the body.

The same request without the token returns:

HTTP/1.1 401 Unauthorized
{"error":"Unauthorized"}

Common API Headers (with Examples)

What to Test in Each Part

Turn these into full test sets for real endpoints in the API Testing Scenario Lab.

From Real Projects

I've worked with APIs at the level this page covers: CRUD operations, HTTP methods, JSON and XML formats, and extracting and validating values with JSON path. A good habit from that work: test the full create–read–update–delete cycle for a resource and check each response in detail. Testsigma supports web, mobile and API test automation, so understanding APIs was part of understanding the product I was testing. Read the full request and response — headers often explain why a call failed.

📚 Official documentation: MDN: An overview of HTTP · MDN: HTTP headers

Request Body vs Query Parameters vs Path Parameters

All three send data to the server, but each has a job:

PATCH /api/users/42?notify=true HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...

{ "role": "lead-qa" }

Here 42 picks the user, notify=true is an option, and the body carries the change. Test each one separately: a wrong ID should give 404, a bad option 400, and an invalid body 400 or 422 with a clear error message. Never send passwords or tokens as query parameters, because URLs are stored in server logs and browser history.

FAQs

What is an endpoint in API testing?

The URL of a resource or operation, such as /users/{id}; combined with an HTTP method it defines what the request does.

What are the parts of an HTTP request?

Method, URL (with path and query parameters), headers and an optional body.

What are the parts of an HTTP response?

Status code, headers and an optional body.

Query parameters vs path parameters?

Path parameters identify a specific resource and are part of the path (/users/123); query parameters filter, sort or paginate and come after ? (?status=active).

Content-Type vs Accept?

Content-Type is the format of the body you send; Accept is the format you want back.

Can a GET request have a body?

Technically it can, but its meaning isn't defined and many servers and proxies ignore it — send GET inputs as path or query parameters.

What are headers in an API?

Headers are key-value pairs sent with a request or response that describe it rather than carry the data: for example Content-Type (format of the body), Authorization (credentials), Accept (format you want back) and Cache-Control.

What is a request body in a REST API?

The request body is the data sent after the headers, usually JSON, for example the fields of a user you want to create with POST. GET and DELETE requests normally have no body.

Should data go in the request body or in query parameters?

Put data you're creating or changing in the body, and use query parameters for options like filtering, sorting and paging. Sensitive values such as passwords and tokens belong in the body or headers, never in the URL.

Related

• API Testing Fundamentals
• The Complete API Testing Tutorial
• Response Validation in REST Assured
• Top 30 API Testing Interview Questions