What Is an HTTP Request? Methods, Headers, and Examples

An HTTP request is a message a client sends to a server to ask for a resource or trigger an action. Every web page load, API call, image fetch, form submission, and login attempt starts this way. The method tells the server what the client wants to do, the URL points to the target, headers add context, and the optional body carries data. The HTTP standard defines request semantics such as methods and status handling in RFC 9110 [source: RFC Editor].

TLDR: An HTTP request is the client’s structured message to a server, such as GET /products to load a product list or POST /login to send login details. In a simple online store, a single product page may trigger 40 to 120 HTTP requests for HTML, images, scripts, fonts, tracking calls, and API data. A slower API request that takes 800 ms instead of 120 ms can make the whole page feel broken. The main parts to understand are the method, URL, headers, and sometimes the body.

What an HTTP Request Contains

An HTTP request has a clear structure. It is not just “the browser asking for a page.” It is a formatted message with several parts, and each part affects how the server responds.

• Method: The action requested, such as GET, POST, PUT, PATCH, or DELETE.
• URL or path: The target resource, such as /api/users/42.
• Headers: Extra metadata, such as authentication, content type, language, and caching rules.
• Body: Optional data sent with the request, often used with POST, PUT, and PATCH.

A basic raw request may look like this:

GET /articles/http-request HTTP/1.1
Host: example.com
Accept: text/html
User-Agent: Mozilla/5.0

This request asks the server at example.com for an article page. It says the client accepts HTML. It also identifies the client software through the User-Agent header.

Common HTTP Methods

HTTP methods are verbs. They tell the server what kind of operation the client wants. Misusing them can create security issues, confusing API behavior, and painful debugging sessions.

• GET: Retrieves data. A browser uses GET when you open a web page. GET requests should not change server data.
• POST: Sends data to create something or trigger processing. Login forms, checkout forms, and contact forms often use POST.
• PUT: Replaces a resource. If you update a full user profile at /users/42, PUT may be appropriate.
• PATCH: Updates part of a resource. For example, changing only a user’s email address.
• DELETE: Removes a resource, such as deleting a saved address or an uploaded file.
• HEAD: Requests headers only, without the response body. It is useful for checking if a resource exists.
• OPTIONS: Asks what methods or features are supported. Browsers use it in some cross-origin requests.

Honestly, it feels like many API bugs start with the wrong method. A developer uses POST for every action, then six months later nobody knows which endpoints are safe to retry. That small shortcut can cost hours during an outage.

HTTP Headers Explained

Headers are name-value pairs. They add context to the request. Some are sent automatically by browsers. Others are added by developers, API clients, proxies, or security tools.

Common request headers include:

• Host: Identifies the domain name of the server.
• Accept: Tells the server what response formats the client can handle, such as application/json.
• Content-Type: Describes the format of the request body, such as application/json or multipart/form-data.
• Authorization: Carries credentials, tokens, or keys for protected resources.
• Cookie: Sends stored cookie values back to the server.
• User-Agent: Identifies the client application, browser, bot, or library.
• Cache-Control: Sets caching instructions.

Here is a more practical API request:

POST /api/orders HTTP/1.1
Host: shop.example
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...
Accept: application/json

{
  "productId": 1842,
  "quantity": 2
}

This request creates an order. The method is POST. The path is /api/orders. The Authorization header proves the user is allowed to make the request. The body contains JSON data.

Request Body: When Data Is Sent

The request body is where the client puts data that does not fit cleanly in the URL. It is common in forms and APIs. A body can contain JSON, form data, XML, plain text, binary files, or mixed file uploads.

A POST request with JSON is common in modern APIs:

{
  "email": "alex@example.com",
  "password": "not shown here"
}

A file upload often uses multipart/form-data. A simple form may use application/x-www-form-urlencoded. If the Content-Type is wrong, the server may reject the request or parse the body incorrectly. It drives me crazy that this error can waste 20 minutes when the payload looks fine at first glance.

HTTP Request vs. HTTP Response

A request goes from client to server. A response comes back from server to client. The response contains a status code, headers, and usually a body.

• 200 OK: The request succeeded.
• 201 Created: A new resource was created.
• 301 or 302: The client is redirected.
• 400 Bad Request: The request is invalid.
• 401 Unauthorized: Authentication is missing or invalid.
• 403 Forbidden: The client is known but not allowed.
• 404 Not Found: The resource does not exist.
• 500 Internal Server Error: The server failed while processing the request.

For troubleshooting, always inspect both sides. A request may be malformed. A response may expose the real failure. Browser developer tools and API clients such as curl, Postman, or Insomnia can show the exact headers and body.

Query Strings and URL Parameters

Many GET requests include a query string. This starts after a question mark in the URL:

GET /search?q=http&page=2&sort=recent HTTP/1.1

Here, q, page, and sort are query values. They help filter or shape the result. Query strings are visible in browser history, logs, analytics tools, and server records. Do not place passwords, private tokens, or personal data there.

Path values are also common:

GET /users/42/orders HTTP/1.1

In this case, 42 likely identifies a user. This style is common in REST APIs because it keeps resource paths readable.

Security Considerations

HTTP requests often carry sensitive information. Treat them with care.

• Use HTTPS: Plain HTTP can expose data in transit. HTTPS encrypts the connection.
• Protect tokens: Never log full authorization tokens in application logs.
• Validate input: Do not trust request bodies, query strings, cookies, or headers.
• Limit methods: Disable methods your service does not support.
• Check content length: Large request bodies can be used for abuse.
• Set CORS carefully: Loose cross-origin rules can expose APIs to unwanted browser access.

Practical Example: Loading a Dashboard

Imagine a user opens a sales dashboard at 9:00 AM. The browser first sends a GET request for the HTML page. Then it requests CSS, JavaScript, fonts, and icons. After that, the JavaScript sends API requests for revenue, orders, alerts, and user settings.

A realistic dashboard may send 65 requests during the first load. If 10 of those requests are API calls and 2 are slow, the user may blame the whole product. The interface may appear half-loaded, even if 63 requests worked correctly.

This is why request timing matters. A well-formed request is only part of the story. Teams should also measure latency, failed status codes, payload size, and retry behavior.

How to Inspect an HTTP Request

In most browsers, open Developer Tools and use the Network tab. Reload the page. Click a request. You can inspect the method, URL, status code, headers, cookies, body, timing, and response.

With curl, a request can be tested from the command line:

curl -X GET https://example.com/api/products \
  -H "Accept: application/json"

For a POST request:

curl -X POST https://example.com/api/users \
  -H "Content-Type: application/json" \
  -d '{"name":"Alex","role":"editor"}'

These tools make the request visible. That matters because guessing usually fails. The server only reacts to what it receives, not what the developer intended to send.

Final Takeaway

An HTTP request is the basic unit of web communication. It combines a method, target URL, headers, and sometimes a body. GET retrieves data. POST sends data. PUT, PATCH, and DELETE modify resources in more specific ways.

When a website, app, or API fails, the request is one of the first places to check. Look at the method, headers, authentication, body format, and timing. Small details decide whether the server returns useful data, rejects the request, or fails with an error.