HTTP Request Components

What You’ll Learn

• What an HTTP request looks like
• Key fields that make up a request
• How to send a request of your own

Retrieving Hypertext

Imagine an old-fashioned general store: you’d approach the counter and hand your shopping list to a clerk who knows exactly where everything is stored. Similarly, on the Web, you tell your browser which resource (web page, file, or piece of data) you’d like, and your browser sends a request to the server that can fulfill your wish. It’s a timeless transaction pattern—computers asking each other for stuff!

Your browser’s job is to translate your actions (like typing a URL or submitting a form) into a properly formatted HTTP request. Because the browser acts on your behalf, it’s often called the user-agent. You might also hear the browser referred to as the client in this exchange.

Components of an HTTP Request

Per the HTTP specification, requests should be simple enough to “read” and understand at a glance. Let’s look at an example request for visiting appacademy.io:

POST / HTTP/1.0
Host: appacademy.io
Content-Length: 31
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

username=azure&password=hunter2

Below that, you see some data in the body of the request: username=azure&password=hunter2. This request is more than just a simple “knock” on the door; it also includes information about what we’re sending, in what format, and how the server should handle it.

1. Request-Line

The request-line is the first line of an HTTP request. It sets the stage for the entire request:

• Method (HTTP verb) – e.g., GET, POST, PUT, PATCH, DELETE
• URI (Uniform Resource Identifier) – What resource do you want? For instance, /users/123 could be a URI for retrieving a user with ID 123.
• HTTP version – Typically HTTP/1.1 or HTTP/2.

In our example, POST / HTTP/1.0 means we want to send a POST request to the root of the site (/) using HTTP/1.0. The URI / often refers to the root resource of the application.

2. Headers

Right after the request-line, you’ll see many lines that look like Header-Name: some-value. Headers are key-value pairs that provide metadata about the request. The server uses these headers to interpret how the data should be processed.

In the example request:

• Host: appacademy.io – Tells the server where this request is intended to go.
• Content-Length: 31 – Specifies the size of the request body in bytes.
• Content-Type: application/x-www-form-urlencoded – Tells the server we’re sending form data in a URL-encoded format.

Headers are case-insensitive, so Accept-Encoding or aCcEpT-eNcOdInG are treated the same by the server.

3. Body

After the headers, you’ll sometimes have a body, which contains extra data for the request—like form submissions, file uploads, or JSON payloads in an API call. For instance, when you submit a login form:

username=azure&password=hunter2

This is the body data, describing the form fields you entered. The Content-Type header (application/x-www-form-urlencoded) ensures the server knows how to parse it. Other common content types include application/json, multipart/form-data (for file uploads), and text/plain.

5 Common HTTP Verbs

HTTP verbs convey the action you intend to perform on a resource. They align with the CRUD (Create, Read, Update, Delete) operations:

• GET – Retrieve resources.
  Example: When you type a URL into the address bar, the browser sends a GET request to fetch that webpage. A GET request typically does not have a request body.
• POST – Create new resources on the server.
  Example: Submitting a registration form that creates a new user record in a database.
• PUT – Update an entire resource on the server.
  Example: Sending all fields (name, email, password, etc.) to completely overwrite an existing user profile.
• PATCH – Partially update a resource.
  Example: Only sending an updated email address for your user profile, rather than resending all your user info.
• DELETE – Remove or destroy a resource.
  Example: Sending a request to delete a post or a product listing.

While the server could technically ignore these conventions, following them keeps your code understandable and aligns with best practices. It’s like respecting traffic rules—you could drive on the wrong side of the road, but you’ll cause chaos!

Content-Type Header

For requests that contain a body, you’ll almost always see a Content-Type header. This header specifies how the server should interpret the body data:

• application/x-www-form-urlencoded – Default for HTML form submissions.
• application/json – A format commonly used in APIs, easy to parse with JavaScript.
• multipart/form-data – Used for forms that upload files (images, docs, etc.).

The server expects the body to match the format declared by Content-Type. If you claim you’re sending JSON but actually send plain text, the server might get confused and reject or misinterpret the data.

Other Common Headers

While Content-Type is crucial, browsers automatically add plenty of other headers. Here are a few you’ll likely see:

• Host – Indicates the domain (e.g., appacademy.io) that the request is targeting.
• User-Agent – Contains information about the browser or client (e.g., Chrome, Firefox, etc.). This can include version info, OS details, and more.
• Referer – (Misspelling of “Referrer”) Tells the server the URL you came from, if any.
• Accept – Specifies which media types or data formats the client can handle (like HTML, JSON, or images).

These headers help the server figure out how to respond. For instance, if you set Accept: application/json, you’re telling the server you prefer a JSON response over HTML or XML.

Sending Your Own HTTP Requests

Beyond the browser, you can also send your own custom HTTP requests:

• Command-line tools like curl let you craft requests with custom headers, bodies, and methods right from your terminal.
• Postman or similar API clients provide a graphical interface to build requests, test endpoints, and examine responses.
• JavaScript (for instance, using fetch or axios) within your web apps to programmatically send requests when users click buttons or fill forms.

Once you understand the basic anatomy of a request—method, URI, headers, body—you’ll be able to interact with servers to build powerful web features!

What You've Learned

You’ve just taken a deep dive into the components that make up an HTTP request:

• An HTTP request is the first step in obtaining resources from the web (like a webpage or an API endpoint).
• The Request-Line includes the HTTP verb, the URI, and the HTTP version.
• Headers provide metadata about how the request should be processed.
• The Body contains additional data (like form submissions, JSON, or file uploads) if necessary.
• HTTP Verbs (GET, POST, PUT, PATCH, DELETE) help define the nature of the request (retrieve, create, update, partially update, or delete a resource).
• The Content-Type header (and other headers) plays a huge role in how the server interprets your request.

By mastering these fundamentals, you’ll be able to diagnose tricky bugs, troubleshoot network issues, and design APIs with clarity and precision. Whether you’re filling out a form or building complex web services, HTTP requests form the bedrock of communication on the web.