Request and Response

HTTP requests and HTTP responses

The "client" (the device or browser the user operates) and the "server" that provides information exchange information in a fixed format. What the client sends the server is called an "HTTP request," and what the server sends back is called an "HTTP response." An HTTP response is only ever sent once an HTTP request has been received — a response is never sent on its own.

Teacher Pochi's hintIt's just like calling a courier and asking them to pick up a package — they only come collect it once you've asked. A package is never delivered before you've made that request. HTTP works the same way: the request always comes first, and the response always comes second.

The three parts of an HTTP request

An HTTP request isn't three parts side by side — it's a single message stacked vertically in three tiers, top to bottom.

Let's look at each part in more detail, one at a time.

Teacher Pochi's hintIt's just like a parcel and its shipping slip. The address field on the slip is ① the request line, the special-instructions field on the slip is ② the request headers, and what's actually inside the box is ③ the request body.

The HTTP request line

The request line is the first line of an HTTP request, and it states "what" is being requested and "where." It's made up of three parts: the "method," the "path (URL)," and the "HTTP version."

This example means: "fetch the page index.html, using the GET method, following the rules of HTTP/1.1."

Teacher Pochi's hintIt's just like the address field on a parcel's shipping slip. It states, right up front, "who" it's going to and "by what delivery method" — before anything else.

What is a method?

A method is the type of instruction telling the server "what to do." Of all the methods out there, the two you'll run into constantly during everyday web browsing are "GET," which fetches information, and "POST," which sends data. API development also makes use of methods like these:

Next, let's look at exactly when the two most common ones, GET and POST, each get called.

Teacher Pochi's hintIt's a lot like the range of requests you can make to a courier — "pickup," "redelivery," "tracking," and so on, a dedicated way to ask for exactly what you need.

HTTP request headers

Request headers carry extra information that the request line alone can't convey. They're written across multiple lines, each in a "name: value" format.

Servers sometimes use this information to adjust what they send back in the response. User-Agent in particular reveals "what device or browser is viewing this," and Referer reveals "where this visit came from" — which is exactly why both are widely used in web analytics and marketing analysis, not just engineering. We cover cookies in more detail in their own dedicated topic.

Teacher Pochi's hintIt's like the "sender" field plus the "special instructions" field on a parcel slip — somewhere to note who it's from, and to jot down extra notes, like "fragile," all separate from the package itself.

What is the HTTP request body?

The request body is where the actual data you want to send to the server is held. Methods that don't send data, like GET, leave it empty, while methods that carry data, like POST, put things like form input into it.

Teacher Pochi's hintIt's like the actual contents inside a parcel. No matter how detailed the shipping slip is, it's pointless if the thing you're actually shipping isn't in the box.

Visiting a page as a user basically calls the GET method

Typing a URL directly, clicking a link, opening a bookmark — all of these "go look at a page" actions basically send their request using the "GET" method. GET is the method for browsing: it asks the server to "just show me" the information at the specified location.

Teacher Pochi's hintIt's like walking up to a courier's service counter and being handed a rate chart or flyer without even asking. You don't have to request anything — the information sitting there is simply handed to you. GET works the same way: it's just an operation to have information shown to you.

POST only gets called when a web page specifically designates a POST action

"POST," on the other hand, is only used when a web page explicitly specifies "use POST here." The classic example is clicking a form's submit button: if the HTML <form> tag has method="post" set, submitting it sends a POST request. Without that specification, GET is used instead — so it helps to think of POST as a special method reserved for a deliberate moment of action.

What gets sent isn't just the values the user actually typed in. Values from hidden fields the site's developer built into the page ahead of time go along too, both bundled together as parameters in the request body.

Teacher Pochi's hintIt's like filling out a shipping slip at a courier's counter and handing over the package. Only once you've filled in the slip and handed it over together with the package does the courier take it. POST works the same way: only once you hand over everything you've filled in does the server process it.

What is a parameter?

A parameter is a "value" included in a request and passed along to the server. A parameter is written in "key=value" form, like name=Pochi&email=pochi@example.com, and multiple parameters are joined with &.

GET and POST place these parameters in different locations.

With GET, the parameter is tacked directly onto the end of the URL, while with POST it's hidden away inside the request body — so looking at the URL alone won't tell you what parameters were sent.

Teacher Pochi's hintIt's like a field on a parcel's shipping slip. A label like "Recipient" or "Phone number" is paired with whatever you actually write in next to it. GET is like writing that content directly on the slip, visible to anyone, while POST is like sealing it inside the box, invisible from the outside.

Pros and cons of passing parameters via GET vs. POST

Values you don't want visible to others, like passwords, should generally be sent via POST. Information you'd want to share as just a URL later, like search filters, is a good fit for GET.

Teacher Pochi's hintGET is like an address written boldly on a shipping slip, and POST is like the same information sealed inside the box. The slip is easy for anyone to glance at and check, but its contents are wide open. The sealed box keeps its contents hidden, which buys you some privacy.

The three parts of an HTTP response

Now let's turn to the HTTP response side. A response is likewise a single message stacked vertically in three tiers, not laid out side by side.

Teacher Pochi's hintIt's like the receipt you get when a package arrives. A one-line "received" (① the status line), a few notes about the delivery (② the response headers), and the actual contents that arrived (③ the response body) — all bundled together.

The HTTP status line

The status line is the first line of an HTTP response, and it states the result of the request. It's made up of three parts: the "HTTP version," the "status code," and a "reason phrase."

What each status code actually means (the 200s, 400s, 500s, and so on) is covered in detail in the dedicated Protocol (HTTP) topic.

Teacher Pochi's hintIt's like a courier's delivery result. A tracking site shows the "delivery system's version," a "status code for the delivery result," and a one-line explanation like "delivered" — together, these three sum up "what happened to the package" in a glance.

HTTP response headers

Response headers tell the browser extra information about how to handle the response body. Like request headers, they're written in "name: value" form.

The browser uses this information to correctly interpret and display what it receives. We cover cookies and caching in more detail in their own dedicated topics.

Teacher Pochi's hintIt's like a "handle with care" sticker on a parcel. It's attached separately from the package itself, telling you how to handle the contents (the response body) inside.

The HTTP response body

The response body is where the actual data the server returns is held. For a web page, that's the HTML used to display it; for an API, it might be data in JSON format — either way, it lives here.

Which format comes back is announced to the browser by the "Content-Type" header we saw on the previous slide.

Teacher Pochi's hintPicture the actual parcel that shows up at your door. The status line is the one-line "delivered," the response headers are the notes stuck to the package, and the response body is the contents of the package itself.

Summary

An HTTP request is made up of three parts — the "request line," "request headers," and "request body" — and an HTTP response is likewise made up of three parts: the "status line," "response headers," and "response body."

Requests also come in different "methods," and the two you'll see most, GET and POST, differ in how they pass parameters and when they're used. You can dig deeper into each of these in the dedicated topics below.

Related topics:

• Protocol
• Domain
• Cookie
• Session
• Cache
• What Are Web Fundamentals?

🏠 Back to top