Every time you open a website, fetch data from an API, submit a form, or upload a file, your application communicates with a server.
But what does that communication actually look like?
How does a browser tell a server which resource it wants? How does the server communicate whether the request succeeded? And how do they exchange information about authentication, caching, content types, and security?
The answer lies in three fundamental building blocks of HTTP communication:
Requests — messages sent by a client to a server.
Responses — messages returned by the server.
Headers — metadata that provides additional information about requests and responses.
In the previous article, we explored what HTTP is, why it is stateless, and how authentication works despite that statelessness.
Now, let's look at how HTTP messages are structured and how to understand them when working with APIs.
1. What Is an HTTP Request?
An HTTP request is a message sent by a client to a server to request a resource or perform an operation.
The client could be a browser, a mobile application, a frontend built with React, or another backend service.
For example, imagine that your frontend needs to fetch a list of users from a backend API.
It might send this request:
GET /api/users HTTP/1.1
Host: example.com
Accept: application/json
This tells the server that the client wants to retrieve the users resource and can accept a JSON response.
The structure of an HTTP request
A traditional HTTP/1.1 request has the following structure:
Request Line
Headers
Optional Blank Line + Message Body
Let's break it down.
1.1 Request line
The request line contains three parts:
GET /api/users HTTP/1.1
Method: GET — describes the intended operation.
Request target: /api/users — identifies the target resource.
HTTP version: HTTP/1.1 — identifies the HTTP version used by this message.
Other common HTTP methods include POST, PUT, PATCH, and DELETE. We'll explore them in a future article.
1.2 Request headers
Headers provide additional information about the request.
For example:
Host: example.com
Accept: application/json
Authorization: Bearer <access-token>
Content-Type: application/json
These headers communicate different things:
Host identifies the target host (where we are requesting a resource) in HTTP/1.1.
Accept describes the response media types the client can accept.
Authorization carries credentials used for authentication.
Content-Type describes the media type of the request body, when one is present.
Not every request needs every header. Their presence depends on the request and the application's requirements.
1.3 Request body
A request body carries data sent by the client.
For example, when creating a user, a client might send:
POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
Accept: application/json
{
"name": "Ashay",
"email": "ashay@example.com"
}
Here, the body contains the user data in JSON format.
A request body is common with methods such as POST and PUT, but the HTTP method alone doesn't always determine whether a body can exist. For example, GET requests generally shouldn't include content unless a specific, well-defined use case supports it.
The server processes the request according to the endpoint's implementation, validation rules, authentication requirements, and business logic.
2. What Is an HTTP Response?
After receiving and processing a request, a server sends an HTTP response.
A response communicates the outcome of the request and may include the requested resource or other useful information.
For example:
HTTP/1.1 200 OK
Content-Type: application/json
[
{
"id": "101",
"name": "John Doe"
},
{
"id": "102",
"name": "Jane Doe"
}
]
In this example, the server returns a successful response containing a JSON array of users.
The structure of an HTTP response
A traditional HTTP/1.1 response has this structure:
Status Line
Headers
Optional Blank Line + Message Body
Let's examine each part.
2.1 Status line
The status line contains the HTTP version, status code, and a reason phrase in HTTP/1.1.
For example:
HTTP/1.1 200 OK
HTTP version: HTTP/1.1
Status code: 200
Reason phrase: OK
The status code communicates the outcome of the request.
2.2 Response headers
Response headers provide metadata about the response.
For example:
Content-Type: application/json
Cache-Control: no-cache
Set-Cookie: session_id=abc123; HttpOnly; Secure
These headers can tell the client how to interpret the response, how to handle caching, or whether to store a cookie.
2.3 Response body
The response body contains the returned representation or other response content, when applicable.
For example:
{
"id": "101",
"name": "John Doe",
"role": "developer"
}
A response body is common when an API returns data, HTML, or an error document.
However, not every response includes a body. For example, a 204 No Content response indicates that the request succeeded and there is no response content to return.
3. What Are HTTP Headers?
We've already seen headers in both requests and responses. Now let's understand them in more detail.
HTTP headers are fields that carry metadata and control information associated with HTTP messages.
They help clients and servers communicate information beyond the request target or response status.
For example, headers can communicate:
- Which media types the client accepts.
- What format the request body uses.
- Whether authentication credentials are present.
- How a response can be cached.
- Which security policies apply.
- Information about content negotiation and representation metadata.
HTTP headers are generally written as field names followed by a colon and a value in HTTP/1.1:
Content-Type: application/json
Accept: application/json
Cache-Control: no-cache
Header names are case-insensitive, so Content-Type and content-type refer to the same field name.
Headers can appear in requests, responses, or both, depending on the field's defined purpose.
A quick note about HTTP versions
The examples in this article use the traditional HTTP/1.1 text format because it is easy to read and understand.
4. Different Types of HTTP Headers
For our understanding, we can group commonly encountered headers into several categories.
4.1 Request headers
Request headers provide information about the client, its preferences, the request context, or the credentials being presented.
Examples include:
Accept
Accept: application/json
Indicates that the client can accept JSON responses.
Authorization
Authorization: Bearer
Carries credentials used by the server to authenticate the request.
User-Agent
User-Agent: ExampleClient/1.0
Identifies the client software. The exact format and usefulness of this value depend on the client.
Origin
Origin: https://app.example.com
Identifies the origin associated with a request, particularly in browser security and CORS scenarios.
Request headers help the server understand the context of an incoming request, but their presence doesn't automatically make the request trustworthy. The server must validate security-sensitive information.
4.2 Response headers
Response headers provide information about the server's response and instructions or metadata for the client.
Examples include:
Set-Cookie
Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax
Instructs the browser to store a cookie according to its attributes and cookie policies.
Location
Location: https://example.com/new-page
Identifies a URI associated with a redirect or another response that uses this field.
Cache-Control
Cache-Control: no-store
Directs caches not to store the response.
Access-Control-Allow-Origin
Access-Control-Allow-Origin: https://app.example.com
Indicates which origin is permitted by the server's CORS policy for browser-based cross-origin access.
Response headers often determine how browsers and other clients handle the response, rather than simply describing its content.
4.3 Representation and content-related headers
These headers help describe the representation being sent or provide information relevant to its interpretation.
Content-Type
Content-Type: application/json
Indicates the media type of the message content.
Content-Encoding
Content-Encoding: gzip
Indicates the content coding applied to the representation.
Content-Language
Content-Language: en
Identifies the language or languages intended for the representation.
Content-Length
Content-Length: 128
Indicates the content length in bytes when applicable to the message framing.
These headers are useful because the client needs to understand what it received and, where relevant, how to interpret or decode it.
4.4 Authentication-related headers
Authentication-related headers communicate credentials or authentication challenges.
Authorization
Authorization: Bearer
Used by a client to present credentials to the server.
WWW-Authenticate
WWW-Authenticate: Bearer realm="api"
Sent by a server to indicate an authentication scheme or challenge.
Proxy-Authorization
Proxy-Authorization: Basic
Carries credentials intended for a proxy that requires authentication.
Proxy-Authenticate
Proxy-Authenticate: Basic realm="proxy"
Used by a proxy to indicate its authentication requirements.
These fields have different roles depending on whether authentication is being performed with an origin server or a proxy.
4.5 Caching headers
Caching headers help clients and intermediary caches decide whether a response can be reused and whether it needs revalidation.
Cache-Control
Cache-Control: max-age=3600
Allows a response to be considered fresh for up to 3,600 seconds, subject to the applicable caching rules.
ETag
ETag: "v1-abc123"
Provides a validator for a particular representation.
If-None-Match
If-None-Match: "v1-abc123"
Allows a client to ask whether the representation still matches a previously received entity tag.
Last-Modified
Last-Modified: Fri, 16 Oct 2026 08:00:00 GMT
Indicates when the representation was last modified, when the server provides that information.
If-Modified-Since
If-Modified-Since: Fri, 16 Oct 2026 08:00:00 GMT
Allows a client to request a response based on whether the representation has changed since a specified time.
For example, if a cached representation is still valid, the server might return 304 Not Modified, allowing the client to reuse its cached copy instead of downloading the representation again.
4.6 Security-related headers
Security-related response headers can instruct browsers to apply certain security protections.
Strict-Transport-Security
Strict-Transport-Security: max-age=31536000
Instructs supporting browsers to use HTTPS for future requests to the relevant host for the specified duration, subject to the header's rules.
Content-Security-Policy
Content-Security-Policy: default-src 'self'
Defines restrictions on the sources from which a browser may load certain resources.
X-Content-Type-Options
X-Content-Type-Options: nosniff
Helps prevent browsers from interpreting certain responses as a different content type through MIME sniffing.
Referrer-Policy
Referrer-Policy: strict-origin-when-cross-origin
Controls how much referrer information the browser includes in requests.
These headers can strengthen browser-side security, but they are not substitutes for proper authentication, authorization, input validation, and secure application design.
Conclusion
HTTP communication is built around requests and responses.
A request tells the server what the client wants to do and may include headers and a body. A response communicates the outcome through a status code and may return headers and a body.
Headers provide additional information about the request or response, including content types, authentication, caching, and security policies.
Understanding these building blocks is essential for anyone working with frontend applications, backend APIs, mobile applications, or web infrastructure.
In the next part of our Deeper Dive into HTTP series, we'll explore what happens beneath these messages: how HTTP communication travels across the network, the role of TCP and UDP, connection reuse with Keep-Alive, and what changes with HTTP/3.
If you found this useful, follow AshayCodes - Instagram and YouTube for more practical explanations of the technologies we use every day.
Happy learning!
Top comments (0)