HTTP requests, headers, bodies, and methods

Most activity on the web follows one fundamental conversation pattern. The client sends a request, and the server sends back a responseConcept · lights on your mapresponseThe server’s answer, “here’s the result,” carrying a status code and usually some data. The other half of the web’s fundamental conversation; the client’s side is the request..

When you load a page, submit a form, place an order, refresh a feed, or scroll for more content, the client and server exchange requests and responses. Each time, the same pattern.

A modern web application may perform thousands of these exchanges. Some technologies also support longer-lived connections and continuous streams of information, but the request–response model remains the starting point for understanding web communication.

In this lesson, we will examine the first half of the conversation: the request.

What is a request?

A requestConcept · lights on your maprequestA structured message from client to server, “here’s what I want.” One half of the web’s fundamental conversation; the server’s answer is the response. is a structured message that a client sends to a server.

The request tells the server what the client wants and may include information the server needs to perform the action.

For example, when a user places a coffee order, the application might send a request containing:

• The action being requested
• The destination within the server
• Information about the request
• The drink and size being ordered
• Proof of who the user is

Consider this simplified HTTP request:

This example uses the text-based appearance of HTTP/1.1 because it makes the request easy to read.

Newer versions of HTTP may transmit the same concepts using more efficient binary representations, but the underlying structure (method, destination, headers, and data) remains similar.

The request line

The first line is called the request line: POST /orders HTTP/1.1

It contains three pieces of information:

• POST is the HTTP method.
• /orders is the path being requested.
• HTTP/1.1 is the version of HTTP used in this example.

You can read the line approximately as: use the POST method on the /orders path using HTTP version 1.1.

In many applications, this particular request might mean: submit information to create a new order.

However, the method and path do not carry that meaning automatically. The engineers designing the server decide what should happen when it receives this combination.

What are HTTP methods?

An HTTP method communicates the general kind of action the client wants the server to perform.

Methods are sometimes informally called HTTP verbs because words such as GET, POST, and DELETE describe an intended action.

The two most common methods are GET and POST.

GET: retrieve information

A GETConcept · lights on your mapGETThe HTTP method that retrieves information: loading a page, fetching an order. Meant to be safe to repeat, which is why a browser can reload one freely. Its counterpart for sending information is POST. request asks the server to return information.

Examples include:

• Loading a webpage
• Retrieving an order
• Requesting search results
• Loading additional posts in a feed
• Downloading an image

A request to retrieve order number 1042 might begin like this: GET /orders/1042 HTTP/1.1

GET requests are intended to retrieve information without making an important change to the server’s data.

That expectation matters. Browsers, caches, and other systems may repeat GET requests because they are supposed to be safe to perform more than once.

Poorly designed software can violate this convention, but well-designed systems generally avoid using GET for actions such as charging a card or deleting an account.

POST: submit information for processing

A POSTConcept · lights on your mapPOSTThe HTTP method that submits information for processing: creating an order, submitting a form, attempting a payment. Unlike GET, repeating one may repeat the action, which is why browsers warn before resubmitting. request sends information to the server and asks it to process that information.

Examples include:

• Creating an order
• Submitting a form
• Sending a message
• Uploading a file
• Attempting a payment

The coffee-order example begins with: POST /orders HTTP/1.1

The request includes data describing the order so that the server can validate it, calculate the total, process the purchase, and save the result.

Repeating a POST request may sometimes repeat the action. Submitting the same payment request twice, for example, could risk creating two charges unless the system has protections against duplication.

This is why a browser may warn you before resubmitting a form after refreshing a page.

Other common HTTP methods

You will also hear several other methods, namely PUT, PATCH, and DELETE:

• PUTRecognition — just know it existsPUTThe HTTP method that commonly replaces a complete resource. A convention the server must be designed to support. Recognition-level for now. commonly replaces a complete resource.
• PATCHRecognition — just know it existsPATCHThe HTTP method that commonly changes part of an existing resource, rather than replacing the whole of it as PUT does. commonly changes part of an existing resource.
• DELETERecognition — just know it existsDELETEThe HTTP method that requests a resource be removed. Like PUT and PATCH, a convention rather than something the protocol enforces. requests that a resource be removed.

For example, PATCH /orders/1042 HTTP/1.1 might update part of order 1042, while DELETE /orders/1042 HTTP/1.1 might request that the order be deleted.

These meanings are conventions rather than automatic commands. The server must be specifically designed to support the method and decide what action it performs.

For now, the useful mental map is:

• GET: retrieve
• POST: submit or create
• PUT: replace
• PATCH: partially update
• DELETE: remove

What are headers?

After the request line come the headersConcept · lights on your mapheaderLabeled metadata about a request or response: which host, what format, who’s asking. Information about the message rather than the message itself, which is the body..

Headers are labeled pieces of information describing the request and how it should be handled.

Consider the first header: Host: api.coffeeapp.com

This tells the receiving infrastructure which host the request is intended for, which is useful because one server or group of servers may handle several domain names.

The next header is: Content-Type: application/json

This tells the server that the request body is written in JSON format.

The server needs to know the format so that it can interpret the body correctly, and if it expects JSON but receives another format, it may reject the request.

The final header in the example is: Authorization: Bearer x81k…

This carries information the server may use to identify or authorize the requester.

You do not need to understand bearer tokens yet. Authentication and authorization will receive their own lessons later; for now, recognize that identity and access information can travel in a request header.

Headers are examples of metadata: information about the message rather than the primary content of the message.

What is the body?

After the headers comes a blank line, followed by the bodyConcept · lights on your mapbodyThe primary content a request or response carries: the order being submitted, the page being returned. Distinct from the headers, which only describe it.: { "drink": "latte", "size": "large" }

The body contains the primary information the client is submitting.

In this example, the body is written in JSON. You can already recognize its structure from Module 3. It contains labeled values describing a drink and its size.

Not every request has a body. GET requests commonly send the information they need through the URL and headers instead.

POST, PUT, and PATCH requests frequently include bodies because they often need to submit information to the server.

What is a payload?

Engineers often use the word payloadConcept · lights on your mappayloadThe meaningful data being transported by a request or response. Close enough to “body” in most conversations; “the backend validates the payload” means it checks that data before trusting it. for the meaningful data carried by a request or response.

In this example, the JSON order information is the request’s payload.

People frequently use body and payload as though they mean the same thing, and in many conversations that is close enough.

More precisely, the body is a particular section of the HTTP message, while payload is a broader term for the useful data being transported.

When an engineer says: “the backend validates the payload,” they mean that the server checks the submitted information before trusting or using it.

It might check whether:

• A drink was provided
• The size is allowed
• The item is available
• The values use the expected data types
• Required information is missing
• The requester has permission to place the order

This is the input validation and business logic you encountered in earlier modules.

Reading the complete request

Return to the full example at the top of this lesson.

You can now read it in plain English: send a POST request to the /orders path on api.coffeeapp.com. The body uses JSON. The request includes authorization information. The submitted order is for a large latte.

That request may travel through several networks and pieces of infrastructure before reaching the software responsible for handling orders, and the server then reads it, validates the data, applies its business logic, and prepares a response.

The mental model to remember

An HTTP request is a structured message sent by a client to a server.

The request line contains the method, path, and HTTP version.

The method describes the general action being requested.

Headers contain labeled information about the request.

The body contains information submitted with the request.

The payload is the meaningful data being transported, often contained in the body.

The most common methods are:

• GET retrieves information.
• POST submits information for processing.
• PUT commonly replaces information.
• PATCH commonly updates part of something.
• DELETE requests removal.

You should now be able to look at a simplified HTTP request and identify what action is being requested, where it is going, what information describes it, and what data it carries.