Understanding HTTP Requests and Responses

Hello again. You have already established how an IP address, port, and transport protocol identify a communicating process, and why TCP is commonly used when an application needs complete, ordered data. HTTP is the application-level convention that gives that byte stream meaning: it tells a server what a client wants and tells the client what happened.

In this lesson, you will learn to read the essential parts of an HTTP request and response: request methods and paths, headers, bodies, status codes, and the distinction between metadata and application data. This is foundational for later system-design work, where an API is the visible contract between clients and services.

---

HTTP turns a connection into a conversation

A browser, mobile app, or backend service acts as an HTTP client when it sends a request. A web server, API service, or reverse proxy acts as the HTTP server when it returns a response.

At the network layers discussed so far, a client might have a TCP connection to:

api.example.com:443

TCP reliably carries ordered bytes between the endpoints. But TCP does not say whether those bytes mean “fetch a user profile,” “create an order,” or “the requested page was not found.” HTTP supplies that shared vocabulary.

A typical exchange has two messages:

1. The client sends an HTTP request, describing the desired action and target.
2. The server sends an HTTP response, reporting the outcome and, often, returning data.

For readability, this lesson uses the visible text format of HTTP/1.1. HTTP/2 and HTTP/3 encode and transport messages differently, but their core semantics remain: methods, targets, status codes, headers, and bodies still have the same roles.

Before examining each piece, watch this short overview from Codecademy. It connects the client-server exchange to the TCP-based request flow from the previous lesson.

---

The shared anatomy: start line, headers, blank line, body

In HTTP/1.1, both requests and responses use the same broad shape:

start line
Header-Name: value
Another-Header: value

optional body

The empty line is meaningful. It marks the end of the headers and the beginning of the optional body. This matters because TCP gives HTTP only a stream of bytes; HTTP’s syntax lets the receiver determine where metadata stops and content begins.

Read the central parts of MDN’s HTTP messages guide now. It uses HTTP/1.1 because the visible format makes the protocol easier to learn, then shows that the same concepts continue into later versions.

The word optional is important for bodies. A GET request usually has no body; its target identifies the resource being requested. A successful GET response usually does have a body because the server is returning the requested representation. In contrast, a 204 No Content response deliberately has no response body.

---

Interpreting a request

Consider a mobile client retrieving public information about user 42:

GET /v1/users/42?include=avatar HTTP/1.1
Host: api.example.com
Accept: application/json
Accept-Language: en-US
Authorization: Bearer <access-token>

Read it from top to bottom.

1. The request line: method, target, version

The first line is the request line:

GET /v1/users/42?include=avatar HTTP/1.1

It has three parts:

Part	Example	Interpretation
Method	GET	The action the client is asking the server to perform
Request target	/v1/users/42?include=avatar	The resource path and optional query parameters
HTTP version	HTTP/1.1	The message syntax version used for this exchange

The target is normally a path, such as /v1/users/42, plus an optional query string, beginning with ?. The query string supplies modifiers such as filters, search terms, pagination cursors, or optional fields. Here, include=avatar asks for an augmented representation; it does not identify a different network destination.

The hostname is usually not repeated in the request line. Instead, HTTP/1.1 uses the Host header:

Host: api.example.com

This allows one server or reverse proxy to serve multiple domain names at one IP address and port. IP routing gets a request to the machine or load balancer; Host helps the HTTP layer select the intended virtual site or service.

2. Methods state intent

The HTTP method does not mechanically enforce behavior. It communicates an intended operation, and the server implements the endpoint’s actual rules. Still, standard meanings make APIs predictable.

Method	Usual intent	Example
GET	Retrieve a representation; should not change server state	Fetch a profile or product
POST	Submit data for server-side processing, often creating a subordinate resource	Create an order
PUT	Create or fully replace the resource at a known target	Replace a saved preference document
PATCH	Partially update an existing resource	Change only a user’s display name
DELETE	Request removal of a resource	Delete an uploaded image
HEAD	Obtain response metadata without a response body	Check whether a resource has changed

For an interview, avoid saying “POST always creates and PUT always updates.” Those are common conventions, not universal laws. A stronger statement is:

GET reads a resource, while POST, PUT, PATCH, and DELETE express state-changing intent under the API’s contract.

You will define API contracts more formally in Module 2. For now, focus on being able to interpret what a request is attempting.

3. Headers carry metadata and instructions

Each header has a case-insensitive name and a value:

Accept: application/json

Headers are not the core domain object being transferred. They are metadata and protocol instructions that help the recipient interpret or handle the request or response.

In the example request:

• Host: api.example.com identifies the intended HTTP host.
• Accept: application/json says the client can accept a JSON representation in the response.
• Accept-Language: en-US communicates a language preference.
• Authorization: Bearer ... carries credentials that the service can use to authenticate the request.

A useful distinction:

• Accept describes what response formats the client is willing to receive.
• Content-Type describes the format of a body that is actually being sent.

For example, a client creating a URL short link may send:

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

{"url":"https://example.com/articles/intro"}

Here, Content-Type: application/json tells the server how to interpret the bytes after the blank line. Content-Length states the body size in bytes in this HTTP/1.1 example. The server can use these details to frame and parse the incoming body.

Do not put sensitive credentials into a URL query string casually. URLs may appear in browser history, logs, analytics, or intermediary systems. Authentication information conventionally belongs in an authorization header and must be protected in transit with HTTPS, the topic of the next lesson.

4. The request body carries application data

The request body is the content after the blank line:

{"url":"https://example.com/articles/intro"}

A body can carry JSON, form data, binary file contents, or another agreed format. It is common on POST, PUT, and PATCH requests. A body is not an automatic guarantee that an operation is valid: the service must still validate the data, authenticate the caller, apply business rules, and return an appropriate response.

For a system-design discussion, you can describe a request in one sentence:

The client sends POST /v1/links with a JSON body containing the destination URL, an authorization header identifying the caller, and an Accept header requesting JSON in return.

That is far more informative than merely saying, “The client calls an endpoint.”

---

Interpreting a response

Suppose the server accepts the short-link request, stores the mapping, and creates a new resource. It might return:

HTTP/1.1 201 Created
Content-Type: application/json
Location: https://api.example.com/v1/links/aZ91Qp
Cache-Control: no-store

{
  "code": "aZ91Qp",
  "shortUrl": "https://sho.rt/aZ91Qp",
  "destinationUrl": "https://example.com/articles/intro"
}

1. The status line reports the outcome

The response begins with a status line:

HTTP/1.1 201 Created

It contains:

1. The HTTP version.
2. A numeric status code.
3. A human-readable reason phrase, such as Created.

Applications should rely primarily on the numeric code; the reason phrase is explanatory text and is not the durable API contract.

Status codes are grouped by their first digit:

Class	Meaning	Examples
1xx	Informational	Rarely important in ordinary API design discussions
2xx	The request succeeded	200 OK, 201 Created, 204 No Content
3xx	Further action or redirection is needed	301 Moved Permanently, 302 Found
4xx	The request cannot be fulfilled as sent	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 429 Too Many Requests
5xx	The server or a dependency failed to fulfill a valid request	500 Internal Server Error, 503 Service Unavailable

A few high-value interpretations:

• 200 OK: the request succeeded, typically with a response body.
• 201 Created: a new resource was created. The Location header commonly identifies it.
• 204 No Content: the request succeeded, and there is intentionally no response body.
• 400 Bad Request: the service could not understand or validate the supplied request.
• 401 Unauthorized: in common HTTP usage, the client has not provided valid authentication credentials.
• 403 Forbidden: the server understood the request but will not permit this caller to perform it.
• 404 Not Found: no resource was found at that target, or the service chooses not to reveal whether one exists.
• 500 Internal Server Error: the server encountered an unexpected failure.
• 503 Service Unavailable: the service is temporarily unable to handle the request, often because it is overloaded or undergoing maintenance.

A 4xx response generally points to a problem the caller needs to change: malformed data, missing credentials, a nonexistent path, or exceeding a limit. A 5xx response generally points to a server-side or dependency problem. This distinction later informs retry policies: blindly retrying a malformed 400 request is pointless, while a carefully bounded retry may be reasonable for certain transient 5xx failures.

2. Response headers explain the returned representation and next steps

In the example:

Content-Type: application/json
Location: https://api.example.com/v1/links/aZ91Qp
Cache-Control: no-store

• Content-Type says that the body is JSON.
• Location gives the URL of the newly created resource.
• Cache-Control gives instructions about whether and how intermediaries or clients may cache the response. no-store is appropriate when a response should not be retained.

Other response headers you will encounter frequently include:

Header	Meaning
Content-Length	The size of the body, where applicable
Content-Encoding	An encoding applied to the body, such as compression
Set-Cookie	Instructs a browser to store a cookie
ETag	A version-like identifier useful for caching and conditional requests
Retry-After	Suggests when a client may try again, often with 429 or 503

Caching headers will become a major design concern in Module 5. At this point, recognize that headers let a server communicate behavior around the body, not merely the body’s format.

3. The response body returns a representation or error detail

The body in the 201 Created response is JSON describing the created link:

{
  "code": "aZ91Qp",
  "shortUrl": "https://sho.rt/aZ91Qp",
  "destinationUrl": "https://example.com/articles/intro"
}

The server does not have to return its internal database record exactly as stored. A response body is a representation chosen for the API client. It may omit internal fields, combine data from multiple services, or format the data for the client’s needs.

Error responses often include a body too:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "invalid_url",
  "message": "destinationUrl must be an absolute HTTPS URL"
}

The status code communicates the broad category of failure. The body gives the client actionable, API-specific detail.

---

A complete trace: from browser action to HTTP messages

Imagine a browser loading:

https://news.example.com/articles/system-design

At a high level:

1. The browser resolves news.example.com to an IP address and reaches a service listening on the appropriate port.
2. It establishes the needed transport and security context. For HTTPS, HTTP messages are protected by TLS; you will unpack that in the next lesson.
3. The browser sends an HTTP request, often similar in meaning to:

GET /articles/system-design HTTP/1.1
Host: news.example.com
Accept: text/html
Accept-Language: en-US

4. The server, CDN, reverse proxy, or application service processes the request and returns a response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: public, max-age=300

<!doctype html>
<html>
  ...
</html>

5. The browser reads 200 as success, uses Content-Type to decide that the body is HTML text, and renders it. While parsing that HTML, it may discover images, stylesheets, and scripts, causing further HTTP requests.

The original document’s response says nothing magical about the images or JavaScript embedded in the page. Each referenced asset is normally fetched through its own HTTP request, though modern HTTP versions can efficiently share connections.

---

Inspect HTTP rather than guessing

In practice, browser developer tools make HTTP visible. Chrome DevTools’ Network tab is one of the most useful entry-level debugging tools: it lets you see actual methods, URLs, status codes, timings, headers, and bodies instead of inferring them from frontend behavior.

When a page or API call behaves unexpectedly, inspect a request in this order:

1. Request URL and method: Did the client call the expected endpoint with the intended action?
2. Status code: Did the server report success, a caller error, a redirect, or a server failure?
3. Request headers and payload: Were authentication credentials, content type, query parameters, and body data sent as intended?
4. Response headers: Is the content type correct? Is the response cached, redirected, compressed, or rate-limited?
5. Response body: Does the returned data or error detail explain what happened?

A brief hands-on habit: open any ordinary website, press the browser’s developer-tools shortcut, select Network, refresh the page, and click the main document request. Identify its method, status code, Content-Type, and one caching-related header. You do not need to understand every header; practice reading the ones that answer a concrete question.

---

HTTP semantics versus HTTP versions

It is useful to distinguish what HTTP means from how a version sends it.

• HTTP/1.1 presents messages in a text-like form with a request line or status line, headers, and body.
• HTTP/2 transmits the same meanings in binary frames and can multiplex several request-response streams over one TCP connection.
• HTTP/3 retains core HTTP semantics while using QUIC over UDP as its transport foundation.

So an API design such as “POST /v1/links returns 201 Created and JSON” is an HTTP-level contract. It remains meaningful regardless of whether the client and server negotiate HTTP/1.1, HTTP/2, or HTTP/3.

This distinction is especially useful in interviews. You normally describe the API at the semantic level:

Clients use GET /v1/links/{code} to retrieve link metadata. A successful response returns 200 and JSON; an unknown code returns 404.

You would discuss HTTP/2, HTTP/3, connection multiplexing, or transport selection only when performance, network quality, or connection scale makes them relevant.

---

Key takeaways

• HTTP is an application protocol that structures the bytes carried by a network connection into requests and responses.
• A request contains a method, target path and query, HTTP version, headers, a blank line, and an optional body.
• Methods express intent: GET reads, while POST, PUT, PATCH, and DELETE commonly request state changes.
• Headers are metadata and instructions. Host, Accept, Authorization, Content-Type, Cache-Control, and Location are particularly useful to recognize.
• A response begins with a status line whose numeric status code communicates success, redirection, client error, or server error.
• The response body carries the selected representation or useful error detail, while response headers explain how to interpret and handle it.
• Browser network tools let you inspect real request-response exchanges and are often the fastest path to diagnosing web behavior.
• HTTP describes message semantics, not confidentiality. Plain HTTP traffic can be observed or altered by parties on the network path.

Next, you will examine HTTPS and TLS: how the client and server authenticate and establish encryption so HTTP requests, headers, and bodies can travel securely across untrusted networks.